Компьютерное устройство для выполнения прикладных программ - RU2210803C2

Код документа: RU2210803C2

Чертежи

Показать все 40 чертежа(ей)

Описание

Область техники, к которой относится изобретение
Настоящее изобретение относится к компьютерным устройствам и, более конкретно, к компьютерным устройствам для разработки и выполнения прикладных компьютерных программ.

Уровень техники
Компьютерные устройства для разработки и модификации прикладных компьютерных программ, включающие в себя написание текстов программы (кодов) или программных объектов (далее - "объектов") используют парадигмы программирования, примерами которой являются языки третьего поколения ("3GL"), языки четвертого поколения ("4GL") или методологии объектно-ориентированной разработки ("OOD"). При этом само по себе компьютерное устройство, подходящее для разработки и модификации прикладных компьютерных программ и содержащее в качестве своих основных компонентов процессор, блок памяти и носитель данных, известно из множества источников, например, книги Кагана Б.М. Электронные вычислительные машины и системы (М.: Энергоатомиздат, 1991, с.143, 339-341). Из публикации WO 96/31828 также известно компьютерное устройство для использования прикладной программы, имеющее процессор, блок памяти и носитель данных, и содержащее ряд моделей, записанных на носителе данных, каждая из которых содержит данные, включающие в себя ссылки на один или более объектов, и техническую программу системы управления, адаптированную для загрузки с носителя данных в блок памяти одной выбранной из ряда моделей, считывания данных выбранной модели и активации и выполнения объекта после считывания ссылки на указанный объект. Одним из важнейших ограничений этих традиционных методологий является то, что для их использования в разработке и модификации программ разработчик должен практически изменить текст программы (код). Это ограничение причиняет большие неудобства не только с точки зрения рабочего времени, необходимого для указанного изменения программы, но также и с позиции координации действий по разработке и тестированию программного обеспечения.

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

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

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

Помимо проблем, связанных с необходимостью написания и стыковки нового текста программы для разработки или модификации приложений, еще одна проблема в существующих способах разработки и модификации прикладных программ состоит в том, что такое кодирование должно включать в себя обработку внешних событий таких, как пользовательского ввода/вывода или иных обстоятельств. Однако в связи с тем, что такой пользовательский ввод/вывод или иные обстоятельства для различных пользовательских окружений могут значительно различаться (например, графический пользовательский интерфейс - интерфейс GUI - по сравнению с вводом символов), для обеспечения возможности адаптации таких принципиально различных внешних событий с использованием существующих методик требуется либо (1) длительный по времени процесс разработки пользовательского программного обеспечения и его отладка, либо (2) разработка пакета программ, учитывающего возможность работы в широком диапазоне условий и обладающего способностью работать в различных известных средах приложений. В обоих случаях для каждой локальной среды прикладной программы необходима трудоемкая процедура написания и тестирования программ только для того, чтобы либо сохранить недостатки программы, что повлечет за собой изменения в среде приложения, либо выполнять сложный процесс повторного кодирования программы и ее отладки каждый раз при изменении указанных внешних условий.

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

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

Зарегистрированными моделями могут являться только модели, не содержащие ссылок на методы, имеющие возможность активирования других методов.

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

Блок администратора событий в этом случае может быть выполнен с возможностью проверки наличия вариантной модели для данной образцовой модели при активации образцовой модели, поиска данной модели при наличии вариантной модели, проверки наличия условий для найденной вариантной модели и выполнения данной вариантной модели при наличии условий для найденной вариантной модели.

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

В общем случае блок администратора событий может выполнен с возможностью выполнения действий, являющихся внешними по отношению к моделям, после выполнения каждого из объектов, входящих в модель. Наибольшее значение настоящего изобретения заключается в том, что оно позволяет обойтись без кодированных прикладных программ за счет замены программы блоком администратора событий и библиотеками моделей, методов или иных объектов, обладающих возможностью динамического связывания и многократного использования, подробное описание которых приводится ниже. Вместо исходного кода программы, объектного кода или исполняемой прикладной программы в любой иной форме, обладающей возможностью динамического связывания, которая служит в качестве приложения, в варианте осуществления настоящего изобретения предлагается единый, независимый от приложения программный объект, который здесь и далее обозначается как блок администратора событий (RTEM). Администратор событий представляет собой единый управляющий объект, который используется во время работы любых приложений, разработанных в соответствии с настоящим изобретением. Администратор событий постоянно определяет действия компьютера путем активации тех доступных средств, которые наиболее подходят для данного состояния приложения и средства ввода/вывода в любой конкретный момент времени. Однако блок администратора событий на самом деле не включает в себя функциональные возможности, которые блок администратора событий определяет как целесообразные, а только активирует средства - включая объекты, специфические для данного приложения объекты и инструментарий - необходимые для реализации данной функциональной возможности. Термин "инструментарий", используемый в настоящем документе, обозначает процедурный код, который разрешает или предоставляет доступ к функциям низкого уровня или функциям операционной системы, например, описанная ниже инструмент доступа к базе данных ("DBAC") считывает из базы данных и записывает в базу данных информацию. Термин "Средство использования инструмента", используемый в настоящем документе, обозначает объект построения модели, разрешающий доступ к инструменту, то есть объект, который формирует интерфейс для работы с инструментом, например параметры выполнения СЧИТЫВАНИЯ или ЗАПИСИ с использованием DBAC. Эти объекты и инструменты (которые включают в себя методы, инструменты ввода/вывода или прочие программные структуры, способные реализовать на компьютере определенные функциональные возможности) не работают независимо от управления со стороны блока администратора событий. Другими словами, блок администратора событий и только блок администратора событий активирует их в первую очередь и определяет выполняемые ими задачи.

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

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

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

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

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

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

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

В варианте осуществления настоящего изобретения блок администратора событий также использует инструменты для изменения шаблона и формата входной и выходной информации периферийных средств, включая постоянное хранение данных (базы данных), внешние формы выдачи (входной и выходной) информации (экраны, отчеты) и процессы обмена данными в электронной форме (обычный "EDI" - электронный обмен данными). Для этого блок администратора событий использует инструменты, а также наборы инструментов, далее именуемые "расширенные пакеты инструменты", с помощью которых обрабатываются входные и выходные данные с периферийных средств: (1) контроллер доступа к базам данных ("DBAC") (инструмент) и (2) пользовательские средства ввода/вывода, описание которых приведены ниже. Использующийся далее термин "Расширенный пакет инструментов " относится к пакету инструментов. Например, для представления пользователю всех данных блок администратора событий обращается к расширенному пакету инструментов пользовательского средства ввода/вывода, содержащему вспомогательную программу ввода, которая воспринимает информацию, полученную от пользователя с помощью клавиатуры, и вспомогательную программу для презентации, позволяющую отображать данные в различных форматах (например, в формате GUI интерфейса или с помощью символов). Пакет инструментов для презентации могут содержать вспомогательные программы ввода, отображения текста и экранный драйвер, которые могут использоваться согласно способам, известным специалистам в данной области техники.

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

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

В варианте осуществления настоящего изобретения блок администратора событий активирует DBAC с целью ликвидировать зазор между логическим "гибким" просмотром хранящихся данных и фактическими столбцами и строками RDBMS (реляционных систем управления базами данных- RDBMS') (негибкими). DBAC управляет хранением и поиском гибких строк данных в нескольких обычных таблицах, управляемых RDBMS. Для всех прочих объектов используется та же процедура регистрации (описана ниже), что и для моделей. Процесс регистрации определяет гибкие (или вариантные) зависимости способом, отсутствующим в обычных RDBMS. Для более эффективной работы логика DBAC может быть распределена между задачами клиента и сервера. Не требуется предварительно создавать таблицу, предпочтительно ее отсутствие, эту таблицу можно модифицировать в соответствии с последующими изменениями, например в соответствии с логическим присоединением вариантной информации в некоторые или все ее строки.

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

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

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

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

В варианте осуществления настоящего изобретения блок администратора событий использует пользовательские средства ввода и вывода (UIO) для поддержки взаимодействия между приложением и его UIO. Эти пользовательские средства ввода и вывода включают в себя средства ввода и вывода, расположенные вне компьютера и связанной сети, и включают в себя экранные формы, средства ввода данных, процессы обмена данными в электронной форме ("EDI" - электронный обмен данными) и прочие средства ввода-вывода.

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

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

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

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

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

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

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

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

Перечень фигур чертежей
Фиг. 1 представляет собой архитектуру варианта устройства в соответствии с настоящим изобретением.

Фиг. 2 представляет собой вариант интерфейса приложения и пример набора библиотеки моделей или разработок в соответствии с настоящим изобретением.

Фиг. 3 представляет собой организацию блок администратора, моделей, методов и данных в соответствии с вариантом осуществления настоящего изобретения.

Фиг. 4 представляет собой пример шаблона формы варианта модели в соответствии с настоящим изобретением.

Фиг. 4А представляет собой еще один пример шаблона модели, показанный более подробно, чем на фиг. 4.

Фиг. 4В представляет собой более подробное описание первой части структуры данных модели и обрабатываемой информации для данной модели.

Фиг. 4С представляет собой более подробное описание второй части структуры данных модели (продолжение фиг. 4В)и обрабатываемой информации для данной модели.

Фиг. 5 представляет собой частный пример модели в соответствии с настоящим изобретением для внедрения меню приложения.

Фиг. 5А представляет собой частный пример вариантной модели в соответствии с настоящим изобретением.

Фиг. 5В представляет собой таблицу, содержащую информацию о вариантной модели.

Фиг. 6 представляет собой блок-схему регистрации объектов, включая модели, входящих в вариант осуществления настоящего изобретения.

Фиг. 6А представляет собой блок-схему работы инструмента для разработки моделей, связанный с процедурой регистрации, показанной на фиг. 6.

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

Фиг. 7В представляет собой вторую часть блок-схемы для создания программы тестирования TestBed, предназначенной для использования при тестировании моделей в процессе разработки или модификации приложений, используемом в варианте осуществления настоящего изобретения.

Фиг. 8 представляет собой блок-схему работы варианта блока администратора событий согласно варианту осуществления настоящего изобретения.

Фиг. 9 представляет собой блок-схему, описывающую часть работы варианта блока администратора событий, представленного на Фиг. 8, относящейся к вариантным моделям.

Фиг. 10 представляет собой блок-схему, описывающую часть работы варианта блока администратора событий, представленного на Фиг. 8 и 9, относящейся к загрузке и выгрузке вариантных моделей.

Фиг. 11 представляет собой наглядный пример базового файла и базовой записи для гибкой базы данных.

Фиг. 12 представляет собой наглядный пример описаний двух наборов вариантов для гибкой базы данных.

Фиг. 13А представляет собой первую часть блок-схемы, описывающей стадии, использующиеся при определении нового набора вариантов в гибкой базе данных.

Фиг. 13В представляет собой вторую часть блок-схемы, описывающую стадии, использующиеся при определении нового набора вариантов в гибкой базе данных.

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

Фиг. 14 представляет собой блок-схему, описывающую процедуру открытия словаря данных в гибкой базе данных.

Фиг. 15 представляет собой блок-схему, описывающую процедуру открытия логического файла в гибкой базе данных.

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

Фиг. 16В представляет собой вторую часть блок-схемы, описывающую процедуру определения, какие именно наборы вариантов относятся к выбранной базовой записи в гибкой базе данных.

Фиг. 17А представляет собой первую часть блок-схемы, описывающей стадии, включенные в функцию "СЧИТЫВАТЬ" инструмента доступа к базе данных.

Фиг. 17В представляет собой вторую часть блок-схемы, описывающей стадии, включенные в функцию "СЧИТЫВАТЬ" инструмента доступа к базе данных.

Фиг. 18А представляет собой первую часть блок-схемы, описывающей стадии, включенные в функцию "ИЗВЛЕЧЬ" инструмента доступа к базе данных.

Фиг. 18В представляет собой вторую часть блок-схемы, описывающей стадии, включенные в функцию "ИЗВЛЕЧЬ" инструмента доступа к базе данных.

Фиг. 19 представляет собой блок-схему, описывающую стадии, включенные в функцию "ПРОВЕРИТЬ" инструмента доступа к базе данных.

Фиг. 20 представляет собой блок-схему, описывающую стадии, включенные в функцию "СОЗДАТЬ" инструмента доступа к базе данных.

Фиг. 21 А представляет собой первую часть блок-схемы, описывающую стадии, включенные в функцию "ЗАПИСАТЬ" инструмента доступа к базе данных.

Фиг. 21В представляет собой вторую часть блок-схемы, описывающую стадии, включенные в функцию "ЗАПИСАТЬ" инструмента доступа к базе данных.

Фиг. 22 представляет собой блок-схему, описывающую стадии, включенные в функцию "УДАЛИТЬ" инструмента доступа к базе данных.

Фиг. 23 представляет собой блок-схему, описывающую стадии, включенные в функцию "ЗАКРЫТЬ" инструмента доступа к базе данных.

Фиг. 24 представляет собой блок-схему, описывающую стадии, включенные в функцию "ОТКЛЮЧИТЬ" инструмента доступа к базе данных.

Фиг. 25 представляет собой блок-схему, описывающую стадии, включенные в функцию "ПОЛУЧИТЬ КЛЮЧ" инструмента доступа к базе данных.

Фиг. 26 представляет собой блок-схему, описывающую стадии, включенные в функцию "ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ" инструмента доступа к базе данных.

Сведения, подтверждающие возможность осуществления изобретения
Фиг. 1 представляет собой архитектуру варианта устройства, выполненного в соответствии с настоящим изобретением. Администратор событий 10, подробно описанный ниже на фиг. 8-10, представляет собой набор процедур, ответственных за выполнение всех операций, связанных с каким-либо приложением. Администратор событий 10 имеет доступ к
различным данным и объектам, включая словарь данных 12, стандартные модели 14, дополнительные модели разработчиков 16, локальные модели 18 и локальную среду 20. "Стандартными" или "образцовыми" моделями 14 называют модели, предоставленные авторами конкретного приложения, предназначенные для выполнения процедур, связанных с данным приложением и содержащие правила, определяющие алгоритм работы данного приложения. Стандартные или образцовые модели 14 обеспечивают основные стандарты для работы приложения. "Дополнительные" модели 16 разработчиков предоставляются авторами приложения в качестве альтернативных вариантов стандартных или образцовых моделей как в целом, так и в какой-либо части, с целью использования в процедурах, которые хотя и отличаются от стандартных или образцовых процедур, тем не менее могут быть активированы приложением. Например, в параметрах приложения по материально-техническому снабжению, в котором представлена модель подготовки продукта, может быть использована дополнительная модель, применяемая для сбора входных данных и обновления различных файлов только в определенных условиях, например, если включен модуль перевозки автотранспортом. Локальными моделями 18 называют модели, разработанные специально для конкретного участка использования данной прикладной программы и имеющие уникальную конфигурацию в соответствии с требованиями к этому приложению на данном участке. Например, локальные модели могут включать в себя операции, относящиеся к локальному участку, например они могут быть связаны с оборудованием, операторами и пр. данного участка. Локальная среда 20 представляет собой совокупность данных и условий, описывающих конкретные параметры, при которых должно работать данное приложение.

Администратор событий 10 также имеет доступ к набору контроллеров. Первый из этих контроллеров представляет собой средство обработки данных 22, которое осуществляет обработку данных в соответствии с моделью, заданной блоком администратора событий 10, как описано ниже. Все зарегистрированные объекты, которые входят в приложение (а именно модели, методы, данные, текст и пр. ), и все вспомогательные объекты, такие как инструменты, называют "средство обработки данных". Средство обработки данных 22 создает перекрестные ссылки между всеми объектами и всеми прочими объектами, связанными с ними и разработанными в соответствии с известными в данной области техники способами, что позволяет обеспечить доступность объектов и их понимание для разработчиков.

Второй контроллер, к которому имеет доступ блок администратора событий 10, представляет собой контроллер доступа к базе данных ("DBAC") (со стороны клиента) 24. DBAC (со стороны клиента) 24 позволяет блоку администратора событий получить доступ к базе данных через, если это необходимо, промежуточные программные средства, включающие, например, связь по сети или разделяемый блок памяти 28. Кроме того, DBAC (со стороны сервера) 30 позволяет осуществлять связь с программными средствами баз данных, как имеющимися в продаже, так и являющимися собственными разработками, необходимую в соответствии с моделями, содержащими данное приложение. Например, блок администратора событий DBAC (со стороны сервера) 30 может взаимодействовать с драйвером 32 открытых средств связи с базами данных (ODBC) и RDBMS Oracle^® 34, или с сервером SQL3 38 и системой управления объектно-ориентированными базами данных (OODBMS) Oracle^® 8, 40, или с файловым сервером BASIC 42 и файловой системой BASIC 44, или с любыми прочими подходящими программными средствами баз данных. Через описанные выше программные средства баз данных блок администратора событий 10 получает доступ к данным 36, хранящимся на файловом сервере (не показан). Описание организации программы и данных, входящих в блок администратора событий 10, а также объектов и данных, к которым блок администратора событий имеет доступ, приводится в описании фиг. 3.

Третий контроллер, к которому имеет доступ блок администратора событий 10 в приведенном варианте осуществления настоящего изобретения, является пользовательским средством ввода-вывода 26, в качестве которого преимущественно используется расширенный набор инструментов. Пользовательское средство ввода-вывода 26 использует блок администратора событий 10 для реализации взаимодействия между приложением и его внешними средствами ввода-вывода для того, чтобы эти функции не пришлось выполнять моделям, входящим в состав приложения (или объектам, ссылки на которые приводятся в указанных моделях). Здесь и далее средствами ввода-вывода называются средства, расположенные вне компьютера и связанной с ним сети и включающие в себя экранные формы, средства ввода данных и процессы обмена данными в электронной форме ("EDI" - электронный обмен данными).

Приложение, разработанное и работающее в соответствии с приведенным вариантом осуществления изобретения (в котором блок администратора событий 10 имеет доступ к функциональным возможностям пользовательских средств ввода-вывода 26), не нуждается в разработке или модификации с целью введения модуля, определяющего адрес, из которого вызываются записанные в блоке памяти рабочие данные и по которому они направляются. Таким образом, в указанное приложение не требуется включать логический модуль для размещения данных, например в экранной форме, в отчетном документе или в процессах электронного обмена данными; также это приложение не нуждается во взаимодействии с каким-либо средством или процессом, осуществляющим обмен данными с приложением. Кроме того, структуры данных, созданные в соответствии с настоящим изобретением, преимущественно не содержат процедурных или декларативных подпрограмм, которые позволили бы разработчику обойти эти правила.

В варианте осуществления настоящего изобретения пользовательские средства ввода-вывода 26 определяют, например, где и когда обновлялись данные на экране. Эти средства задают графический или символьный режим работы средств ввода-вывода. Также эти средства определяют рабочий язык пользователя. Любое такое внешнее событие должным образом обрабатывается с помощью пользовательских средств ввода-вывода 26. Модели, лежащие в основе приложения, не нуждаются в доработке или модификации в соответствии с указанными функциональными возможностями пользовательских средств ввода-вывода 26. Связь пользовательских средств ввода-вывода через пользовательские средства ввода-вывода 26 позволяет гибко изменять режимы работы различных средств ввода-вывода как функцию условий в конкретный момент времени, а не жестко задавать эти режимы работы с помощью приложения.

На фиг. 2 показан вариант интерфейса приложения и пример набора библиотек моделей или разработок, выполненных в соответствии с настоящим изобретением. По терминологии, использующейся в настоящем изобретении, "модель" представляет собой программный объект, содержащий данные, определяющие правила для среды прикладной программы и, преимущественно, не содержащий подпрограмм. Другими словами, моделью называют пакет данных, составляющий перечень процедур, которые должны быть выполнены для конкретного поднабора приложения (приложений), с которым связана данная модель. Процедуры включают в себя перечень правил, включая правила бизнес-процессов или прикладных процессов и правила механических процессов. Модель в случае ее активации блоком администратора событий, подробно описанным ниже, активирует автономные, многократно используемые, зарегистрированные, открытые для использования объекты, включая "методы", прочие модели или инструменты. Например, для программы материально-технического снабжения модель, связанная со считыванием всех заказов поданному продукту и определяющая степень влияния спроса на доступность данного продукта, может включать в себя:
1. Установить указатель в файле заказов на первой записи для данного продукта.

2. Если текущий заказ относится к данному продукту:
3. Считать текущий заказ;
4. Собрать общие данные об имеющихся в наличии продуктах.

5. Перейти к п. 2.

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

Термин "метод", используемый в настоящем документе, относится к блоку процедурной подпрограммы, созданному для реализации определенной цели и аналогичному подпрограмме обычной программы. В соответствии с настоящим изобретением используются независимые, многократно используемые, зарегистрированные, открытые для использования методы. Другими словами, каждый метод независимо хранится в той библиотеке, в которой он зарегистрирован. Более подробно процедура регистрации метода описывается ниже в связи с описанием фиг. 6, после регистрации метод становится доступной частью библиотеки, которая может быть активирована блоком администратора событий 10 в соответствующий момент времени, определяемый моделью. В соответствии с настоящим изобретением такие объекты, как методы, могут включать в себя родительские объекты, пре-процессы и пост-процессы, которые будут описаны далее.

На фиг. 2 показана логическая среда для моделей двух основных типов и прикладной интерфейс 50 между ними. Модели могут быть двух основных типов: модели прикладного процесса (или бизнес-правила) и механические модели. Эти два типа моделей отличаются уровнем абстракции процесса управления ими. Модели прикладного процесса или модели бизнес-правил осуществляют процедуры, характерные для какого-либо приложения. Например, в приложении для материально-технического снабжения модель прикладного процесса или модель бизнес-правил может осуществлять обработку данных о поступающих заказах или о получении товаров. Логика, связанная с моделью прикладного процесса или бизнес-правил, специфична только для одной из задач приложения и, в общем случае, ее нельзя использовать в каком-либо ином контексте. С другой стороны, механические модели, как правило, выполняют процедуры при низком уровне абстракции и могут быть использованы в различных контекстах приложения. Например, в области материально-технического снабжения механическая модель может выполнять расчет имеющихся на складе запасов или регистрировать время, затраченное на перемещение товаров из пункта А в пункт В склада.

Термин "библиотека", используемый в настоящем описании, обозначает набор организованных определенным образом объектов, доступныхдля блока администратора событий 10. "Технической программой" называют библиотеку моделей и методов, обладающих возможностью динамического связывания и многократного использования, в частности подборку моделей и методов механических процессов, способных работать друг с другом. В приведенном на фиг. 2 примере набор технических программ (52-62, четные) для приложения, предназначенного для материально-технического снабжения, показан в связке с интерфейсом 50 данного приложения. Техническая программа отказов 52 определяется как группа моделей механических процессов, имеющих дело с событиями отказов. Диспетчерскими техническими программами 54 называют группу моделей механических процессов, выполняющих функции рассылки. Техническими программами выписывания счетов 56 называют группу моделей механических процессов, занимающихся составлением счетов, и так далее, соответственно для технической программы активности 58, складской технической программы 60 и прочих технических программ 62.

На фиг. 2 показана часть содержимого только одной из технических программ. Так техническая программа выписывания счетов 56 содержит механическую модель 70, которая, в свою очередь, содержит ссылку на метод 1, 72 и метод 2, 74; оба указанных метода могут активировать, по крайней мере, один из поднаборов блоков процедурных подпрограмм 78. В механической модели 70 также содержится ссылка на другую механическую модель, 76, которая, в свою очередь, содержит ссылки на два метода: метод X, 80, и метод Y, 82. Ограничения, накладываемые на форму модели и методы, описаны в связи с описанием фиг. 6.

На фиг. 3 показана организация блока администратора событий, моделей, методов и данных в соответствии с вариантом осуществления настоящего изобретения. В настоящем варианте блок памяти содержит четыре раздела: память задач 90, собственная кэш-память задач 100, общедоступная кэш-память со стороны сервера 110 и файловая система 120. Память задач 90 содержит в одной своей части объектную подпрограмму 92 блока администратора событий 10. В другой части памяти задач 90 содержится одна или более таблица переменной ("VTAB") 94, содержащая указатели 96 предварительно скомпилированного банка данных (PCDB) и динамические таблицы переменных 98. Каждая модель, созданная в соответствии с настоящим изобретением, содержит данные, как показано ниже на фиг. 4 и 5, и хранится в предварительно скомпилированном банке данных, который блок администратора событий 10 загружает в момент активации модели. Содержащиеся в модели данные отформатированы таким образом, что блок администратора событий может активировать модель на основе этих данных, которые предпочтительно предварительно скомпилированы таким образом, что язык программирования, используемый в блоке администраторе событий 10, мог бы легко понять содержимое указанных данных и на основе расширения или иных данных, идентифицирующих тип объекта, на который приводится ссылка, найти такие объекты по соответствующему адресу. Собственная кэш-память задач 100 включает набор моделей 102, объектную программу библиотеки методов 104 и собственную кэш-память для файлов данных со стороны клиента 108. Общедоступная кэш-память со стороны сервера 110 содержит набор моделей 112, объектную программу библиотеки методов 114 и общедоступную кэш-память для файлов данных 118. И, наконец, файловая система 120 содержит модели 122 в форме предварительно скомпилированных банков данных 122 (на которые указывают указатели 96 PCDB), объектные программы на диске 124 и таблицы/файлы 126 базы данных.

Администратор событий 10 (показанный на фиг. 1) устанавливает связи VTAB 94 памяти задач с блоком памяти модели 'А' (см. ссылочный номер 102), который представляет собой либо собственную кэш-память для файлов данных со стороны клиента 108, либо общедоступную кэш-память для файлов данных со стороны сервера 118. Данные модели 'А' представлены в форме указателя PCDB (см. ссылочный номер 96), который является сегментом VTAB 94. Соответственно, вне зависимости от размера и сложности модели для связывания ее с VTAB 94 требуется всего лишь несколько машинных команд.

Допустим, например, что стадия 1 (не указана) модели 'А' активирует модель 'В'. Исходя из того, что в каждый данный момент времени активной может быть только одна модель, что подробно описано ниже, блок администратора событий 10 "перемещает" модель 'А' вниз (в стековой структуре системы) и оставляет ее в пассивно связанном состоянии. Затем блок администратора событий 10 устанавливает активные связи с указателем PCDB (см. ссылочный номер 96) модели 'В'.

Далее предположим, что стадия 1 (не указана) модели 'В' дает команду выполнить метод 'X' 106, который является объектной программой. В этом случае блок администратора событий 10 "перемещает" указатель исполнения на метод 'X', который находится либо в собственной кэш-памяти задач 100, либо в общедоступной кэш-памяти со стороны сервера 110. Затем реализуется выполнение метода 'X'.

После выполнения всех этапов модели 'В' блок администратора событий 10 удаляет из стека модель 'В', переводит модель 'А' в активно связанное состояние и переносит указатель стадий на стадию 2.

На фиг. 4 показан пример шаблона 140 модели, который представлен в форме варианта осуществления модели в соответствии с настоящим изобретением. Шаблон 140 модели имеет заголовок 141, содержащий уникальный идентификатор ("ID") модели (в данном случае Example_template), на который указывает указатель PCDB (см. ссылочный номер 96). Хотя на фиг. 4 это не показано, за заголовком 141 следует набор данных, который, по существу, составляет перечень объектов, а затем - необъектные данные. В общем случае объекты включают в себя методы, команды ввода-вывода, команды принятия решений, вспомогательные программы и данные. Каждый элемент перечня, входящего в шаблон 140 модели, может содержать уникальный идентификатор метода, который используется для активации метода из соответствующей библиотеки и который может представлять собой цепочку символов (например, 32 символа), уникальное имя языка, описывающее данный метод, а также указанный в скобках индикатор типа (например, (метод), (ввод), (решение), (данные) и пр.).

Элементы перечислены в последовательности, в которой они должны быть активированы в соответствии с функцией модели. Например, в модели, представленной шаблоном 140, первыми по очереди запускаются Method_142, Method_2 144 и Method_ 3 146. После завершения выполнения Method 3 146 активируется lnput_ 1 148, затем Decision_1 150, Method_n и Тооl_1 154. Процедуры будут выполняться в указанной последовательности до тех пор, пока не будет определен EOL (конец перечня). Элементы данных, перечисленные в шаблоне 140 модели, такие как Data_1 158, Data 2_160, Data_3 162 и Data 4_164, доступны для методов и прочих перечисленных в модели объектов.

На фиг. 4А показан пример еще одного шаблона 1000А для модели, причем этот шаблон показан более подробно, чем на фиг. 4. Здесь информация заголовка модели 1001 содержит ряд признаков: lvmodel$ 1002, идентифицирующий имя модели, lvmodel obj$ 1003, представляющий собой уникальный идентификатор объекта модели, sydescriptn$ 1004, представляющий собой описание модели. Шаблон 1000А также содержит различную управляющую информацию 1005: lvsequence$ 1006 содержит список родительских объектов, подлежащих исполнению, lvexitobject$ 1007 определяет объект, который должен быть выполнен перед выходом из модели (при необходимости выхода из модели этот объект выполнит свои пост-процессы); lvtaborder$ 1008 определяет список номеров поля при составлении последовательности, используемой для перехода с одного поля на другое; lvfirstinput 1009 задает номер поля, с которого начинается процедура после завершения ввода последних данных; Ivlastinput 1010 задает номер последнего поля, которое необходимо обработать перед переходом на первое средство ввода; и lvdata_list$ 1011 задает список всех переменных, используемых в данной модели.

На фиг. 4В приведено более подробное описание первой части 1000В структуры данных с указанием подробной информации о процедуре, выполняемой данной моделью. В данном случае модель осуществляет идентификацию номера объектов, которые определяют модель: {objectid}.name$ 1012 задает имя ссылки на объект (то есть на модель); {objectid}.descriptn$ 1013 задает описание объекта; { objectid}. conditions 1014 задает условие, которое должно быть выполнено для того, чтобы блок администратора событий 10 активировал указанный объект; { objectid} . objecttype 1015 сообщает блоку администратора событий 10 тип настоящего объекта (1: метод, 2: средство использования инструмента; или 3: Модель); { objectid }.module$ 1016 задает модуль для средств использования вспомогательной программы, метода или модели; {objectid}. repository 1017 указывает хранилище данных для средства использования вспомогательной программы или метода; {objectid}.method$ 1018 указывает метод для исполнения; { objectid} . toolusage$ 1019 указывает средство использования вспомогательной программы для исполнения; {objectid}.model$ 1020 указывает модель для исполнения; { objectid }.performflg 1021 указывает блоку администратора событий 10, каким образом получить доступ к данному объекту (0 означает вызов объекта через данные модели, указанные в переменных модели; 1 обозначает то, что объект исполняется с помощью всех данных модели); {objectid}.modelvars$ 1021 предоставляет список переменных модели, которые необходимо направить в метод, средство использования вспомогательной программы или модель; и {objectid} . obj_ var$ 1023 устанавливает список переменных объекта, которые необходимо получить из переменной модели (указывается в переменных модели).

На фиг. 4С приводится дальнейшее описание второй части структуры данных модели (продолжение фиг. 4В) с указанием подробной дополнительной информации о процедурах модели. В частности, она включает в себя параметры: {objectid}. { model_ variable} _{type_of_variable}.usage$ 1024, который задает использование этой переменной, направленной в метод, средство использования вспомогательной программы или модель. Model_variable задает все переменные данные, установленные в {objectid}.modelvars$; {type of variable} определяет следующее: С обозначает символьную переменную; N обозначает цифровую переменную; Usage: I обозначает переменные, направляемые только в одном направлении, В обозначает переменные, направляемые в обоих направлениях, F обозначает переменные, выходящие в виде задаваемой по умолчанию величины и передаваемые назад.

{ objectid} . {model_variable}_{type_of_variable} 1025 задает устанавливаемую по умолчанию величину, направляемую в метод, средство использования вспомогательной программы или модель. { objectid} . action$ 1026 задает действие дополнения для данного объекта (1: пре-процесс; 2: родительский объект или 3: пост-процесс). {objectid}.parentname$ 1027 задает имя родительского объекта, если данный объект относится к пре-процессу или пост-процессу. {objectid}.parent_obj$ 1028 задает идентификатор родительского объекта, если данный объект относится к пре-процессу или пост-процессу. {objectid }. designname$ 1029 определяет тип объекта разработки модели; {objectid}. mandatory 1030 указывает, обязателен или нет входной сигнал, если объект является средством ввода (0 - необязателен, 1 - обязателен); {objectid}. preprocs$ 1031 задает список объектов пре-процесса для данного родительского объекта; и {objectid }.postprocs$ 1032 задает список объектов пост-процесса для данного родительского объекта.

На фиг. 5 показан частный пример 170 модели (а именно, образцовой модели) в соответствии с настоящим изобретением, для ввода меню приложения. После заголовка 171 для Menu_example следует набор из 12 объектов, содержащий восемь методов, ввод и выход. Один из объектов указанной модели, selectVal, является "родительским" объектом. Те объекты, которые предшествуют родительскому объекту (они также отмечаются косой чертой (/)), называют пре-процессами; те объекты, которые следуют за родительским объектом (они отмечаются обратной косой чертой (\)), называют пост-процессами.

При активации модели запускается метод clr_select 172, который стирает переменные, содержащие значения позиции меню, подлежащие выбору. Модель menu_ activ 173 устанавливает (в контексте приложения по материально-техническому снабжению) текущую дату, оператор, терминал, компанию, систему, используемую для слежения за активностью меню, после чего метод menudflt 174 задает устанавливаемые по умолчанию значения такие, как начальное меню, которое выводится при отсутствии выбранных параметров. Метод menu_displ 175 загружает и отображает меню. Метод save_vals 176 сохраняет старые величины, после чего selectVal 177 считывает и сохраняет величины, выбранные пользователем. Модель menuselect 178 подтверждает правильность сделанного пользователем выбора меню. Следующим объектом, который активируется в данной модели, является menusecure 179, который проверяет безопасность меню. Если оператор с помощью меню введет некорректный параметр, или выберет для отображения другое меню, процедура повторится, начиная со метода clr_select 172. Процедуру завершает метод menusecure 179, который направляет специальный запрос (условное обозначение 324 на фиг. 8) на блок администратора событий 10. Если сделанный выбор является правильным (корректная задача), то модель запускает процедуру выхода (объект) 181, которая задает управляющую переменную, сообщающую блоку администратору событий 10 о том, что выполнение модели меню завершено (все пост-процессы процедуры выхода 181 будут выполнены до того, как блок администратора событий 10 фактически выйдет из модели).

Если оператор выберет выход из прикладной среды, то он (или она) при вводе команды выбора меню (selectVal 177) должен нажать предварительно выбранную клавишу (в нашем примере это клавиша F4). При этом вызывается процедура выхода 181, которая устанавливает управляющую переменную, сообщающую блоку администратора событий 10 о завершении процедуры модели меню (все пост-процессы процедуры выхода 181 будут выполнены до того, как блок администратора событий 10 фактически выйдет из модели). Метод menuf4 182 задает условие нажатия оператором клавиши F4 при вводе команды выбора меню (selectVal 177). Menuf4 182 проверяет метку конфигурации системы и определяет, должна ли модель меню вернуться на один уровень отображения меню назад, если еще не достигнут верхний уровень, выйти из меню модели, если верхний уровень достигнут, или выйти из меню модели, если метка конфигурации системы установлена на немедленный выход из модели меню без перехода на предыдущие уровни дисплея меню. Если метод menuf4 182 примет решение о переходе на один уровень дисплея меню вверх, управляющая переменная (для сообщения блоку администратора событий 10 о завершении выполнения меню модели), которой было присвоено значение выхода 181, переназначается и выполняется переход из выбранного для отображения меню в предыдущее меню. Затем процедура продолжается со метода clr select 172.

Переменные данных, связанные с моделью Menu_example 170, включают в себя: action 184, в которой хранятся параметры выбора меню; blank_5 185, в которой хранится 5 пробелов; cmdcompany 186, в которой хранится имя компании; company 187, в которой хранится код компании; menudesc 188, в которой хранится описание меню; oldmenudsp 189, в которой хранятся данные идентичности ранее отображаемого меню; pagedisply 190, в которой хранится вариант отображения страниц; selectval 191, в которой хранятся параметры выбора меню; short_ name 192, в которой хранится сокращенное название компании; status 193, в которой хранится параметр состояния; submenu 194, в которой хранится подменю для системы; terminal 195, которая идентифицирует компьютерный терминал; tilde 196; tilde2 197; и time 198, в которой записано определенное значение времени.

На фиг. 5А показана вариантная модель 170А, созданная на основе образцовой модели 170 фиг. 5. Вариантная модель 170А практически идентична образцовой модели 170. Однако она включает в себя процедуру, отсутствующую в образцовой модели 170, а именно пост-процесс, track_a1 179А, который записывает взаимодействия меню в файл регистрации после проверки безопасности меню. Заголовок 171А вариантной модели 170А обозначает то, что данная модель является вариантной, и идентифицирует ее по имени. Кроме того, в заголовке содержится перечень условий (в данном примере используется только одно условие), необходимых для "применения" вариантной модели 170А и, следовательно, для загрузки и возможной активации. В этом случае условием, необходимым для активации вариантной модели track_a1, является идентичность кода компании А1. Рабочая таблица вариантов модели (которую можно также назвать блоком рабочей карты набора вариантов(сектора набора вариантов)) представляет собой такую же структуру, как и рабочая таблица вариантов DBAC 24, 30, описанная ниже в связи с описанием гибкой базы данных.

Ниже представлены варианты, где один из вариантов относится к модели.

Переменная - track_a1
Условие - Когда компания = А1
Код оценки - 1
Соответствующее выражение для рабочей таблицы будет выглядеть следующим образом:
(COMPANY$="A1")
Где данные, хранящиеся в блоке памяти после базовой записи, читаются как
COMPANY$="A1"
На основе выражения для рабочей таблицы создается рабочий код оценки. В данном примере
(COMPANY$="A1")
Рабочий код оценки в этом случае будет "1". Этот рабочий код оценки сравнивается с приведенными ниже данными, в результате чего определяются активные переменные. Активными переменными называются те переменные, в которых имеется "1" в той же позиции, что и рабочий код оценки.

Рабочий код оценки - 1
Переменная - track_a1 1
Таблица переменных - 1
Активна? - Да
Вариантная таблица соответствует рабочей информации модели. В соответствующем данной вариантной таблице файле хранится таблица всех условий, которые активируют все вариантные модели. В приведенном выше примере вариантная таблица выглядит следующим образом:
LVRTEM.VAR CHECK$="(COMPANY$-"A1")"
LVRTEM.VAR TABLES$="1"
LVRTEM.VARIATIONS$="track_a1"
Чтобы сделать более понятными условные обозначения, принятые в описанных в настоящем описании вариантах осуществления изобретения, приводим следующие разъяснения: LV (использовалось в предыдущем абзаце) относится к классу локальной переменной; прочие приставки используются для обозначения прочих классов переменных, например, SV (системные переменные); DD (словарь данных); DB (база данных); LL (локальная метка); RT (программа).

Подробная, снабженная комментариями версия вариантной модели 170А показана на фиг. 5В, где указано, что вариантная модель загружается, когда COMPANY = "А1" и что в эту модель добавляется объект Toolusage, позволяющий после каждого выбора меню записывать параметры DATE OPERATOR, TIME и SLECTVAL Объект исполняется до присвоения DECISION значения EXIT_MENU. Во-первых, вариантная модель 170А содержит имя объекта, подлежащего добавлению в образцовую модель. Затем в ней указано, куда именно в последовательность процедур данной модели следует вставить данный объект. То есть, данный объект ("track_A1") помещается за родительским объектом "selectval" (условное обозначение 177 на фиг. 5 и 177А на фиг. 5А) как пост-процесс в позицию exit_ menu (условное обозначение 180 на фиг. 5 и 180А на фиг. 5А). Ниже описана подробная процедура, связанная с выбранным в качестве примера объектом "track_a1". В первую очередь, предоставляется описание (DESCRIPTN$), которое вводится в цепочку "Записать в регистрационный файл". В качестве типа объекта принимается величина, обозначающая средства использования вспомогательной программы (в указанном примере эта цифра равна 2). Затем приводится идентификатор родительского объекта 32 (PARENTOBJ$), за которым следует имя родительского объекта (PARENTNAME$) ("selectval", как указано выше). Следующие далее подробные данные содержат имя разработки объекта (DESIGNAME$), то есть "toolusage" - средство использования вспомогательной программы, а также сведения, что в качестве модуля (MODULE$) используется "module". Подробные сведения также содержат обозначение хранилища данных (REPOSITORY$), в котором хранится данный объект; в данном случае это база данных. Далее идет метод, активируемый объектом (TOOLUSAGE$), который определяется как "записать", поскольку track_a1 производит записи в регистрационный файл.

Кроме того, вариантная модель включает в себя список переменных модели (MODEL_ VARS$), содержащий "logfile" (регистрационный файл, входящий в модуль, идентифицируемый как "module"), "write" (записать) (что обозначает операцию), а затем следует список переменных, которые должны быть записаны в случае соблюдения необходимых условий для объекта (то есть, оператор (ZOPRINTFO$(1,6)), время (ТIМЕ$) и выбор меню (SELECTVAL$). Вариантная модель также содержит несколько переменных объекта (OBJ_VARS), в которые входит имя логического файла (SYLFN$), запрашиваемое действие (SYREQUEST$), оператор (OPERATOR$), время (ТIМЕ$) и выбор меню (SELECTVAL$). Вариантная модель активирует DBAC для выполнения записи с использованием указанных выше параметров.

На фиг. 6 показана блок-схема варианта осуществления изобретения для процесса регистрации 200 объектов, включая модели. Процесс регистрации обеспечивает условия, при которых во время проекта разработки приложений все объекты соответствуют определенным ограничениям, которые разрешают их активацию с помощью блока администратора событий 10 и должное исполнение. Процесс регистрации 200 также упрощает тестирование объектов и, в конечном итоге, приложений, которые используют зарегистрированные объекты. Зарегистрированные объекты могут быть активированы более чем одним приложением. Процесс регистрации 200 начинается на стадии 202, с перечисления разработчиком данных конкретного объекта. Эта данные содержат уникальный идентификатор объекта ("ID"), например, 32-х символьный регистрационный идентификатор объекта (не показан на шаблоне модели на фиг. 4). Эти данные также содержат имя родного языка (например, английский) так же, как "Example_template", описанный выше в связи с описанием шаблона 140 модели на фиг. 4. Описание также содержит имя уникального языка (указано в центральном столбце примера шаблона 140 модели на фиг. 4) и в модели Menu_example 170 на фиг. 5, а также индикатор типа, характеризующий данный объект как модель, метод, вспомогательную программу, элемент данных, поле, файл или иной объект. Содержащиеся в объекте данные могут включать в себя идентификатор блока управления разработкой проекта ("DPCU"), автора объекта, идентификатор и имя родного языка объекта для замены или переопределения объекта, а также метку состояния, указывающую, находится ли объект в хранилище данных или в библиотеке.

DPCU представляет собой логический блок операции разработки и может включать в себя любой поднабор проекта разработки приложения. В соответствии с одним из вариантов разработки приложения в соответствии с настоящим изобретением, перед тем, как объектом можно будет пользоваться, регистру разработки объекта присваивается какой-либо DPCU. Присвоение DPCU связывает объект с каким-либо конкретным разработчиком или группой разработчиков, что обеспечивает целостность и качество разрабатываемого объекта. Файл данных DPCU может содержать:
- список авторов или разработчиков объекта;
- список разработанных объектов, за которые отвечает данный DPCU;
- список рабочих заданий, выполняемых DPCU;
- краткое описание заданий для данного объекта;
- развернутое описание заданий для данного объекта;
- дата регистрации данного объекта;
- дата введения данного объекта в эксплуатацию;
- список тестов, подходящих для данного объекта (описание приведено ниже); и
- предполагаемый сигнал для внедрения данного объекта.

Набор тестов является, по существу, списком DPCU, с которыми связаны объекты и которые включены в данный "сеанс тестирования" (описывается ниже). Это позволяет тестировать одновременно несколько проектов по разработке приложений (и, таким образом, объекты, которые они включают в себя), даже тогда, когда включены одинаковые программные процессы. В варианте осуществления настоящего изобретения файл набора тестов разработки содержит:
- список DPCU и, следовательно, подразумеваемый список объектов, которые должны быть включены в тестирование набора;
- список прочих наборов тестов, если таковые имеются, которые при тестировании объединяются с данным набором тестов;
- список зарегистрированных тестировщиков, например, 6-ти символьный код пользователя/присоединения;
- список известных каталогов тестирования (описывается ниже); и
- наименование лица, ответственного за обеспечение качества для набора тестов.

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

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

Контроллер доступа к базе данных (DBAC 24, 30, фиг. 1) автоматически копирует запись из файла продукта, считанную во время сеанса тестирования, если ее формат или описания элементов остались без изменений. DBAC 24, 30 всегда сначала пытается считать записи из каталога тестирования, а в случае неудачи считывает записи, запрошенные из разработанной части базы данных. Использование каталога тестирования предотвращает изменения в данных продукта во время сеанса тестирования.

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

На этапе выполнения разрабатывающий приложение оператор может активировать сеанс тестирования при противоречиях с экраном меню. Набор тестов выбирается из списка, связанного с данным оператором. Затем из списка, прилагаемого к указанному набору и указанному оператору, выбирается нужный каталог тестирования. Во время сеанса тестирования отслеживаются различные данные, включая, но не ограничиваясь следующими:
- выполняемые задачи;
- доступные поля базы данных;
- последовательность нажатия клавиш оператором;
- допущенные ошибки;
- комментарии по тестированию, введенные оператором, и
- результаты тестирования, записанные оператором.

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

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

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

На стадии 204 фиг. 6 разработчик начинает компоновать объект в соответствии со стадиями 206-216 с целью создания модели, имеющей соответствующий формат. Пример такой модели был приведен в связи с описанием фиг. 4 и 5. После завершения компоновки объекта он может стать частью регистра разработок. Объект, помещенный в регистр разработок, можно назвать "объектом разработки" в отличие от "объекта продукта", который зарегистрирован в хранилище продуктов или в библиотеке.

Сущность процесса регистрации 200 может зависеть от типа регистрируемого объекта. Модели (образцовые и вариантные) регистрируются по несколько иным правилам, чем методы и вспомогательные программы.

Модели (образцовые и вариантные) могут быть созданы или модифицированы, например, с помощью инструмента для разработки модели 208. При необходимости внесения изменений, например, в существующую зарегистрированную модель, изменения вносятся в форме вариантной модели. Можно создать любое количество вариантных моделей, соответствующих данной образцовой модели.

Блок-схема логики варианта инструмента для разработки модели 208 показана на фиг. 6А. Инструмент для разработки модели 208 сначала разрешает разработчику приложения на стадии 2081 выбрать модель из списка существующих моделей или создать новую модель, которая будет добавлена к существующему списку. В случае, если выбрана существующая
образцовая модель, то внесенные в эту модель изменения сохраняются в виде вариантной модели конкретной образцовой модели. Затем инструмент для разработки модели 208 начинает выполнение рекуррентного цикла, добавляя все правила, связанные с выбранной моделью. На первой стадии цикла разрешается выбрать на стадии 2082 требуемый объект (по типу), который войдет в выбранную модель. Можно выбирать объекты только из числа зарегистрированных объектов, то есть тех, которые отвечают требованиям к объектам, управляемым блоком администратора событий 10, как описано в настоящем документе. На стадии 2083 разработчик приложения может добавить в модель указанный объект, а также добавить параметры, связанные с выбранными объектами. Напомним, что поскольку модель не содержит подпрограмм, на самом деле не объект входит в модель, а модель содержит ссылку на выделенный объект. Помимо добавления объекта к модели разработчик приложения может изменить или удалить объекты, связанные с данной моделью. Для примера, разработчик модели может выбрать:
- описание данных - определить данные, используемые в данной модели и ввести элемент в словарь данных 12, который указывает на это описание данных (то есть, поле, файл или элемент данных);
- средство ввода - описать средства ввода пользователя, данные, которые сохраняются во введенной пользователем информации, специальные действия, которые предпринимаются для различных результирующих кодов (если есть);
- кнопка - определить описание кнопки, отображаемую надпись, специальные действия, которые предпринимаются для различных возможных результирующих кодов (если есть);
- метод - выбрать активируемый метод и параметры для передачи (если есть); ввести специальные действия, которые предпринимаются для различных возможных результирующих кодов (если есть);
- средство использования инструментов - выбрать средство использования инструментов; ввести специальные действия, которые предпринимаются для различных возможных результирующих кодов (если есть);
- модель - выбрать активируемую модель и параметры для передачи (если есть); ввести специальные действия, которые предпринимаются для различных возможных результирующих кодов (если есть);
- решение - ввести условия для данной стадии принятия решения (если есть) и специальные действия, которые следует выполнить (если есть);
- выход;
- просмотр активации экрана - ввести описания визуального просмотра экрана (понятие просмотра экрана означает функциональную возможность разрешения автоматической прокрутки по мере ввода данных, особенно это относится к повторному вводу данных в следующих друг за другом записях); ввести специальные действия, которые предпринимаются для различных возможных результирующих кодов (если есть);
- описание визуальных параметров просмотра экрана - определение количества визуально отображаемых строк;
- отображение поля - ввести заголовок поля (если есть);
- отображение текста - ввести текст, который требуется отобразить.

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

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

После выполнения процедуры разработки модели, указанной в части А блок-схемы, для конкретной модели инструмента для разработки модели переходит в часть В блок-схемы и в соответствии с известными способами блок администратора событий активирует модель, которая создает указатели предварительно скомпилированного банка данных (PCDB) (см. условное обозначение 96 на фиг. 3), что позволяет обеспечить доступ блока администратора событий 10 к фактической модели. В момент активации модели блок администратора событий 10 загружает данные в предварительно скомпилированный банк данных 96 таким образом, что блок администратора событий 10 при активации модели может выполнять правила, заданные в процессе разработки модели. Если поддерживаемая модель является вариантной моделью, сохраняется только информация вариантной модели и в таблицу вариантной модели вносятся изменения, добавляемые в качестве приложения к обновляемой образцовой модели (то есть, указывается, что вариантная модель существует, и приводятся условия для данных, при которых эта модель активируется). Функциональные возможности каждой стадии вспомогательной программы для разработки модели 208 могут быть реализованы в соответствии с известными способами.

Вернемся к фиг. 6; при необходимости зарегистрировать методы или инструменты на стадии 210, все операции редактирования или поддержки исходной подпрограммы для методов или инструментов осуществляются на стадии 212. Далее подпрограмма (либо исходная, либо объектная) сканируется на стадии 214 на предмет выявления некорректных операций. В варианте осуществления настоящего изобретения средство сканирования на предмет выявления некорректных операций считывает подпрограмму и тестирует ее на наличие ключевых слов, которые являются именами некорректных операций на том языке, на котором написана данная подпрограмма. В общем случае, когда используется язык, который осуществляет передачу, управление или операции ввода-вывода (например, вызов, запись и т.д.), такой язык определяется как некорректный, в этом случае необходимо внесение изменений. Например, в языке Business Basic к некорректным операциям относятся следующие:
ВЫЗВАТЬ ИЗВЛЕЧЬ
ВЫПОЛНИТЬ ПЕЧАТАТЬ
ЗАПИСАТЬ ЗАПУСТИТЬ
СЧИТАТЬ ВВЕСТИ
НАЙТИ ПОЛУЧИТЬ
ЗАКРЫТЬ ОТКРЫТЬ
В процессе регистрации 200 на стадии 216 также определяются параметры, которые были получены во время процедуры сканирования. Любая переменная, которой присвоена какая-либо величина, будет возвращена из метода. Все прочие переменные будут переведены в указанный метод.

Затем все объекты подвергаются процедуре тестирования объекта, начинающейся со стадии 218, на которой определяется тип объекта. Для моделей и вариантных моделей (220) сначала на стадии 222 задается режим TestBed. Режим TestBed позволяет осуществить тестирование модели (или вариантной модели) с использованием фактических или "активных" данных, но без влияния на эти данные истинных файлов. Наоборот, все данные автоматически перемещаются в TestBed в той мере, в какой это необходимо.

На фиг. 7А показана первая блок-схема метода TestBed 240. Когда разрабатываемое и тестируемое приложение, а именно модель, которая является частью приложения, а значит также создается и тестируется, запрашивает операцию ввода-вывода, активируется метод TestBed 240. На стадии 242 метод TestBed 240 определяет назначение запроса: ввод (считывание), вывод (запись) или удаление (стирание).

Если поступил запрос на операцию считывания, то метод TestBed на стадии 244 определяет, содержатся ли данные, которые нужно считать, в TestBed. Если да, то метод осуществляет поиск запрошенных данных на стадии 250. В этот момент метод 240 выполняет несколько стадий, предназначенных для поддержки согласованного функционирования поля, которое накапливает или суммирует подробные данные нескольких записей, это поле можно назвать "сводным полем". Эти стадии, 252-258 (четные), активируются из более чем одной ветви метода 242 и будут более подробно описаны ниже. На стадии 260 процедура возвращается к приложению.

Если на стадии 244 определено, что искомые в операции считывания данные отсутствуют в TestBed, то метод TestBed на стадии R01 определяет, находятся ли данные, которые требуется считать, в файле исключения из TestBed (далее - просто "исключение из TestBed"). В исключении из TestBed хранятся записи, которые были стерты во время последнего сеанса тестирования по одной из следующих причин. "Активная" база данных (содержащая фактические, а не тестовые данные) во время сеанса тестирования не изменяется. Более того, если запись отсутствует в TestBed, ее можно в любой момент восстановить из активной базы данных. Следовательно, системе необходимо знать об удаленных во время сеанса тестирования записях, чтобы не допустить повторного появления удаленных записей в TestBed из активной базы данных во время сеанса тестирования, Эта информация предоставляется хранилищем удаленных в сеансе тестирования записей файла исключения из TestBed. Если данные появятся в исключении из TestBed, то запрашиваемые данные рассматриваются как несуществующие. Данные не возвращаются и процедура на стадии 254 снова переходит к приложению.

Если на стадии R01 определено, что данные в исключении из TestBed отсутствуют, то метод TestBed на стадии R02 определяет, является ли считываемый файл родительским, дочерним или автономным. "Родительским" называют файл, который связан с информацией, хранящийся в одном или более "дочерних" файлов. Например, в контексте материально-технического снабжения рассмотрим файл "Заказы". Данные заголовка заказа могут быть помещены в родительский файл, тогда как такая информация, как строки подробных сведений о продукте, строки замечаний и строки специальных ценовых предложений могут помещаться в один или более дочерний файл с подробными сведениями о заказах, связанный с указанным родительским файлом. Родительские данные могут существовать и без дочерних данных, однако, дочерние данные не могут существовать без родительских данных. Автономным называется файл, в котором отсутствуют связи родительских - дочерних данных. Если на стадии R02 определено, что данный файл является родительским, процедура переходит на стадию R05.

На стадии R05 родительские данные вызываются из активной базы данных и на стадии R06 записываются и блокируются в TestBed. Каждый дочерний файл содержит собственные сведения, связанные с родительскими данными, вызываемые из соответствующих файлов активной базы данных и записываемые на стадии R07 в соответствующие файлы TestBed. После завершения указанной процедуры родительские данные, содержащиеся в TestBed, разблокируются (стадия R08), и на стадии 250 запрашиваемые данные выдаются из TestBed. После стадий 252-258 (четные), в ходе выполнения которых осуществляется работа с согласованными данными сводного поля (как описано ниже), процедура на стадии 254 возвращается к приложению.

Если на стадии R02 определено, что данный файл является автономным, то на стадии 246 запрашиваемые данные выдаются из соответствующей активной базы данных. После выдачи данных все сводные поля на стадии 247 (как описано ниже) очищаются. Затем на стадии 248 происходит обновление TestBed путем записи извлеченных данных в TestBed. Эти данные на стадии 250 выдаются из TestBed, и после стадий 252-258 (четные), в ходе выполнения которых осуществляется работа с согласованными данными сводного поля, процедура на стадии 254 возвращается к приложению.

Если на стадии R02 определено, что данный файл является дочерним, то на стадии R03 определяется, существует ли в TestBed файл родительских данных. Если да, то эти данные на стадии 250 выдаются из TestBed. И снова на стадиях 252-258 (четные) (как описано ниже) осуществляется работа с согласованными данными сводного поля, и процедура на стадии 254 возвращается к приложению. В случае, если на стадии R03 определено отсутствие в TestBed родительских данных для указанного дочернего файла, то на стадии R04 определяется наличие в исключении из TestBed файла родительских данных. Если эти данные имеются, то процедура считает их несуществующими и на стадии 254 возвращается к приложению. В противном случае родительские данные на стадии R05 извлекаются из активной базы данных и на стадии R06 блокируются в TestBed. Каждый дочерний файл содержит собственные сведения, связанные с родительскими данными, вызываемые из соответствующих файлов активной базы данных и записываемые на стадии R07 в соответствующие файлы TestBed. После завершения указанной процедуры родительские данные, содержащиеся в TestBed, разблокируются (стадия R08), и на стадии 250 запрашиваемые данные выдаются из TestBed. После этого процедура на стадии 254 возвращается к приложению.

На фиг. 7В показана вторая блок-схема для метода TestBed 240. Если поступивший запрос имеет целью запись данных, как определено на стадии 242, то на стадии 262 значения, связанные со сводными полями в TestBed, вычитаются из величин, помещенных в сводные поля активной базы данных. На стадии 264 подлежащие записи данные обновляются в базе данных TestBed. Далее на стадии R09 все данные, содержащиеся в исключении из TestBed, стираются. После этого процедура на стадии 266 возвращается к приложению.

На стадии 242, если тип запроса был определен как "удалить", данные на стадии R10 обновляются в исключении из TestBed. На стадии R11 данные удаляются из базы данных TestBed. И, наконец, на стадии 266 процедура возвращается к приложению.

Снова обратимся к фиг. 7А, стадии 252-258 (четные) направлены на осуществление согласования составной переменной в соответствии с настоящим изобретением между данными активной базы данных и TestBed. В варианте осуществления данного аспекта изобретения этой переменной является "сводное поле", которое является количественно характеризующимся полем, в котором содержится сумма нескольких записей с подробной информацией. В примере, связанном с материально-техническим снабжением, сводным полем является запись "мастер продукта", в которой содержится информация об общем количестве данного продукта, находящегося на складе, то есть "под рукой". Подробная информация о том, что именно хранится "под рукой", содержится в записях, относящихся к партии продукта, при этом может быть несколько тысяч партий, относящихся к одной записи о продукте. Для того чтобы быстро определить общее количество продукта, находящегося под рукой в данный момент времени, в базе данных предусмотрено сохранение общего количества продукта, находящегося под рукой, в записи мастер продукта. Каждый раз при изменении подробной записи, связанной с партией продукта, различие, связанное с изменением, добавляется в сводное поле мастера продукта.

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

Чтобы решить проблему отсутствия согласования между сводным полем активной базы данных и базой данных TestBed, TestBed сохраняет в сводном поле сведения обо всех различиях в подробных записях, которые возникли во время последнего сеанса тестирования. К этой величине в сводном поле TestBed прибавляется значение из сводного поля активной базы данных. В TestBed хранятся только изменения, внесенные во время последнего сеанса тестирования. Если записи, содержащиеся в сводных полях, записаны в TestBed, однако, во время сеанса тестирования никаких изменений в сводных полях не выявлено, то значения сводных полей в TestBed составят ноль, независимо от величин, содержащихся в соответствующих сводных полях активных баз данных.

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

Когда сеанс тестирования запрашивает содержащую сводные поля запись, текущие значения, находящиеся в ней на момент получения запроса, вычитаются из (бывших прежде текущими) значений активной базы данных, которые хранятся в блоке памяти на момент поступления запроса на считывание. Результат вычитания представляет собой разность, полученную во время сеанса тестирования. Когда запись, содержащая сводные поля, извлекается из активной базы данных и обновляется в TestBed в первый раз, величинам в сводных полях присваиваются нулевые значения. Все последующие изменения в сводных полях будут хранить только те изменения, которые были внесены в сеансе тестирования.

Снова обратимся к фиг. 7А; в каждом из описанных выше примеров, в котором была достигнута стадия 250, были выполнены процедуры, связанные со стадиями 252-258 (четные). На стадии 252 определяется наличие каких-либо сводных полей. Если такие сводные поля отсутствуют, процедура возвращается на стадии 260 к приложению. Если такие сводные поля имеются, то на стадии 254 они вызываются из активной базы данных. Значения из сводных полей активной базы данных на стадии 256 сохраняются в блоке памяти и значения из сводных полей активной базы данных на стадии 258 прибавляются к значениям из сводных полей TestBed. В результате процедура возвращается на стадии 260 к приложению.

Снова обратимся к процессу регистрации 200 на фиг. 6; при установке TestBed на стадии 222 модель или вариантная модель проходит тестирование на стадии 224. Если на стадии 224 модель не проходит тестирование, то процесс повторяют; разработчик должен внести в модель изменения с помощью, например, инструмента для разработки модели 208, после чего объект подлежит повторному тестированию (стадии 218-224).

В случае, если на стадии 218 было определено, что регистрируемый в настоящий момент объект является методом или инструментом (стадия 226), то на стадии 228 устанавливаются значения параметров указанного метода или инструмента. После задания параметров осуществляется тестирование метода или инструмента. За исключением подпрограмм, встроенных в блок администратора событий 10 (описание приводится ниже), никакие блоки или подпрограммы (например, никакие методы или инструменты) не могут каким-либо образом непосредственно активировать какой-либо другой блок или подпрограмму. Это правило относится ко всем независимо тестируемым блокам или подпрограммам, даже если в момент выполнения подпрограмма находится в стадии разработки.

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

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

Если объект проходит тестирование либо на стадии 224 (для моделей), либо на стадии 230 (для методов и инструментов), то объект можно сделать "общедоступным", то есть доступным для блока администратора событий 10 на время работы приложения. Чтобы сделать объект общедоступным, процесс регистрации создает связанную информацию такую, как "где используется", "как используется", " когда создано" и "когда удалено".

На фиг. 8 показана блок-схема 300, описывающая работу варианта блока администратора событий 10 в соответствии с настоящим изобретением. Администратор событий 10 может быть разработан на языке программирования третьего поколения ("3GL") таком, как Business Basic, С, C++ или на ином подходящем языке третьего поколения.

Администратор событий 10 контролирует работу приложения, которая определяется набором моделей, зарегистрированных в соответствии с процессом регистрации, аналогичным процессу, представленному на фиг. 6. Приведем краткое описание: блок администратора событий 10 загружает исходную модель для приложения, которая определяет исходные процедуры, включая обращения к методам, инструментам и другим моделям. По мере считывания объектов, перечисленных в каждой из моделей, проверяется выполнение условий, описанных для данного объекта, и в случае их выполнения объект активируется. Принимая во внимание, что, как описано выше в связи с описанием процедуры регистрации, зарегистрированный объект не может вызвать другой объект, после завершения выполнения процедуры, связанной с текущим объектом, управление всегда возвращается на блок администратора событий 10. Между всеми процедурами для объектов блок администратора событий 10 может проверять особые действия или внешние условия и обновлять условия таким образом, чтобы к моделям, составляющим приложение, по мере изменения условий сохранялся гибкий доступ согласно этим условиям.

Обратимся к блок-схеме 300; на стадии 302 в блок памяти загружается первая модель. Обратимся к примеру модели для меню пользовательского интерфейса приложения, представленному на фиг. 6А, 6В и 6С; на стадии 302 model_data загружается в локальную память (то есть в память задач 90 на фиг. 1). Этот процесс может включать в себя считывание модели с использованием указателей PCDB 96 (на фиг. 3). Он также включает в себя связывание указателя предварительно скомпилированного банка данных 96 для памяти модели с VTAB 94 памяти задач 90.

На стадии 310 блок администратора событий 10 проверяет наличие вариантной модели, связанной с только что загруженной моделью. Процесс, связанный с проверкой наличия вариантной модели 310, иллюстрируется на фиг. 9. По существу, блок администратора событий 10 проверяет условия всех вариантных моделей, которые были зарегистрированы для загруженной модели, и определяет существование текущих применений на основе состояния данных на момент проверки; если вариантная модель в настоящий момент применима, то она будет загружена (путем помещения на нее указателя PCDB 96) и объединена с данными модели, находящимися на этот момент в блоке памяти.

На фиг. 9 показана блок-схема 400 этого процесса. По достижении стадии 310 блок-схемы 300 блок администратора событий 10 на стадии 402 вызывает первое (или, в зависимости от итерации, следующее) условие, связанное с вариантными моделями для модели, которая была загружена на стадии 302 на фиг. 8. Условия определяются значениями данных в указанной модели. Например:
Condition 1: client$="ACME" and product$="BEACH-BALL"
Condition 2: product$="NET"
Таблица связывает условия с вариантными моделями, которые подлежат активации при соблюдении каждого из условий. Например:
Вариантная модель 'А' и вариантная модель 'В' активируются, когда client$="ACME" and product$="BEACH-BALL"
Вариантная модель 'С' активируется, когда product$="NET"
Администратор событий 10 установит значения проверяемых "текущих условий", например, Condition 1 и затем Condition 2 и т.д. до тех пор, пока не будут проверены все условия относительно текущих значений данных в модели.

На стадии 404 вызванные условия снова проверяются относительно текущих значений данных (хранящихся в таблицах динамических переменных 98 памяти задач 90, фиг. 1). Например:
if checking conditions 1 and
client$="ACME" and product$="BEACH-BALL"
then Models 'A' and 'B' are active
if client$ is not "ACME" or
if product$ is not "BEACH-BALL"
then Models 'A' and 'В' are not active.

Если вызванные условия, проверенные на стадии 404, выполнены или соблюдены (стадия 406), то все вариантные модели, которые должны быть активированы при соблюдении вызванных условий, будут на стадии 410 добавлены в список активных вариантных моделей, хранящихся в памяти задач 90, которая обрабатывается блоком администратора событий 10. Например:
active variant models='A' and 'В'
Если вызванные условия, проверенные на стадии 404, не выполнены, или в случае, когда на стадии 410 в список добавляются все вариантные модели, соответствующие текущим условиям, то блок администратора событий 10 на стадии 408 проверяет, нужно ли проверять какие-либо дополнительные условия для текущей модели. Если да, блок администратора событий 10 возвращается к стадии 402 и вызывает следующее условие из списка. Если нет, то на стадии 412 все вариантные модели, которые были добавлены в список на стадии 410, загружаются в соответствии с описанной выше процедурой загрузки. Все загруженные на данный момент вариантные модели, которые отсутствуют в списке активных вариантных моделей, созданном при выполнении блок-схемы 400, выгружаются, таким образом, что вариантные модели для текущей образцовой модели включают в себя только активные вариантные модели. Указанная загрузка и выгрузка вариантных моделей более подробно описана на примере блок-схемы 500, фиг. 10. После создания списка активных вариантных моделей (с помощью процедуры по блок-схеме 400) этот список сравнивается со списком вариантных моделей, загруженных в данный момент на стадии 502. В результате указанного сравнения устанавливается, какие вариантные модели необходимо активировать (загрузить), а какие вариантные модели необходимо деактивировать (выгрузить).

На стадии 504 выполняется проверка, существуют ли какие-либо загруженные на настоящий момент вариантные модели, отсутствующие в списке активных вариантных моделей. Если такие загруженные на настоящий момент вариантные модели, отсутствующие в списке активных вариантных моделей, отсутствуют, то их деактивация не требуется и процедура переходит на стадию 514, описанную ниже. Однако, если существует одна или более загруженных на настоящий момент вариантных моделей, отсутствующих в списке активных вариантных моделей, то на стадии 506 загруженная на настоящий момент вариантная модель, подлежащая деактивации, вносится следующей в список загруженных на настоящий момент вариантных моделей, отсутствующих в списке активных вариантных моделей.

На стадии 508 информация о загруженных на настоящий момент вариантных моделей, подлежащих деактивации, удаляется из списка управляющих переменных. В блоке администратора событий 10 используется несколько таких управляющих переменных, что позволяет определить, с какими именно объектами и в какой требуемой последовательности следует работать. Управляющие переменные представляют собой, главным образом, перечень объектов. В случае, если в каком-либо из списков управляющих переменных выявлен какой-либо объект, внесенный в список загруженных на настоящий момент вариантных моделей, подлежащих деактивации, то списки изменяются таким образом, чтобы удалить все подобные идентификации указанных объектов. Например, если идентификатор объекта 'M020016TOR1_
0000000000400401_ " (32-символьный или другой соответствующий код), соответствующий загруженной на настоящий момент вариантной модели, подлежащей деактивации, присутствует в списке последовательности родительских объектов (то есть управляющих переменных), он будет исключен из указанного списка.

Затем на стадии 510 из локальной памяти, то есть памяти задач 90, блоком администратора событий 10 будет удалена вся подробная информация для всех вариантных моделей. Например, если вариантная модель какой-либо образцовой модели содержит метод, отсутствующий в образцовой модели, информация об указанном методе (например, модуль, хранилище данных, имя метода и пр.) содержится в данных вариантной модели; если указанная вариантная модель подлежит деактивации, то информация об указанном методе удаляется из блока памяти путем разрыва связей указателя PCDB (условное обозначение 96, из памяти задач 90, показанной на фиг. 3) вариантной модели,
Затем на стадии 512 выполняется проверка, необходимо ли деактивировать еще какие-либо вариантные модели. Если да, блок администратора событий 10 возвращает процедуру на стадию 506, в противном случае или, если на стадии 504 было определено отсутствие вариантных моделей, подлежащих деактивации, на стадии 514 осуществляется проверка наличия каких-либо активных вариантных моделей, отсутствующих в списке загруженных на настоящий момент вариантных моделей. При положительном результате тестирования на стадии 516 подлежащая загрузке текущая вариантная модель вносится следующей в список вариантных моделей, подлежащих загрузке.

Затем на стадии 518 выполняется проверка того, загружена ли уже текущая вариантная модель. Если текущая вариантная модель уже загружена, это не приводит ни к каким действиям. Если текущая вариантная модель еще не загружена, то на стадии 522 она будет загружена вместе с текущими управляющими данными. Администратор событий 10 с помощью управляющих переменных определяет, с какими именно объектами и в какой последовательности следует работать. Все новые объекты, внесенные вариантной моделью, должны быть объединены с указанными управляющими переменными. Это объединение осуществляется на стадии 524. Чтобы блок администратора событий 10 имел возможность определять, когда активировать новый метод, внесенный вариантной моделью, идентификатор объекта для нового метода добавляется в управляющую переменную. Если метод является пре-процессом, он добавляется в список пре-процессов для объекта, который является родительским для данного метода (например, в системе обозначений фиг. 6А-6С { parent object ID}.preprocs$). Как только какие-либо новые объекты, связанные с вариантной моделью, будут объединены с управляющими переменными или, если на стадии 518 было определено, что текущая вариантная модель уже загружена, блок администратора событий 10 проверяет, нужно ли задействовать какие-либо еще активные вариантные модели. Если да, то блок администратора событий 10 возвращается на стадию 516 и вызывает следующую вариантную модель. В противном случае или, если на стадии 514 было определено отсутствие активных вариантных моделей, то на стадии 516 логическая процедура завершается, а управление возвращается либо на стадию 310 фиг. 8, либо на стадию 322 (описана ниже) в зависимости оттого, какая ветвь логической цепочки существовала первоначально.

Предположим, что управление возвращается на операцию проверки вариантных моделей на стадию 310, цикл блока администратора событий 10 верхнего уровня (фиг. 8); на стадии 312 задается значение переменной, идентифицирующей текущий объект, для первого объекта указанной модели. Как описано выше, объектом может быть другая модель, метод, инструмент или другой объект. Администратор событий 10 вызывает первый родительский объект из списка родительских объектов модели. Так, в примере model_menu из фиг. 6А-С:
first_object=lvsequence$(1,32)
- первый родительский объект
Администратор событий 10 также проверяет пре-процесс для данного объекта, например:
pre_processes={first_object).preprocs$
- список пре-процессов для первого родительского объекта
В случае, когда существует какой-либо пре-процесс, первый объект будет задан как первый объект в списке пре-процессов, в противном случае он останется первым родительским объектом. Например:
first_object= pre_processes(1,32)
- первый объект - пре-процесс current_object=first_object
- Задание текущего объекта в качестве первого объекта
На стадии 314 проверяются все условия для текущего объекта относительно текущих данных для определения необходимости выполнения данного объекта. В случае, если с текущим объектом не связаны никакие условия, блок администратора событий 10 считает, что условия удовлетворены или соблюдены. Так, в примере menu_model из фиг. 6А-С:
evaluate {current_object}.condition$
- проверка условий объекта
Если на стадии 314 условие (условия) для текущего объекта соблюдено, то на стадии 316 блок администратора событий 10 загружает и отображает всю информацию, связанную с интерфейсом пользователя, которая требуется для текущего объекта. Эта стадия аналогична процессу "Got focus" -"получение фокуса", как этот термин понимается в области объектно-ориентированного программирования. Например, если текущий объект (который можно представить символом current_ object) является объектом пользовательского средства ввода, например, кнопкой или полем для ввода данных, блок администратора событий 10 сравнивает отображенную в настоящий момент визуальную форму с визуальной формой, в которой отображается текущий объект. Если эти формы различаются, то будет загружена и отображена новая визуальная форма.

Затем на стадии 318 текущий объект активируется. Администратор событий 10 проверяет тип объекта и выполняет соответствующие логические операции для активации или иного использования указанного объекта. Например:
{current_object}.objecttype:
1 = метод - установка параметров и активация метода
2 = средство использования вспомогательной программы - установка параметров и активация средства использования вспомогательной программы
3=модель - установка параметров и активация модели
Таким образом, если текущий объект является моделью, то эта модель загружается на стадии 318а. Если текущий объект является методом, то этот метод загружается на стадии 318b. Если текущий объект является средством использования инструмента, то это средство использования инструмента загружается на стадии 318с.

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

Принимая во внимание, что состояние соответствующих данных во время выполнения объекта может быть изменено, а измененные данные могут повлиять на то, какие вариантные модели будут применены в связи с условиями для указанных вариантных моделей, блок администратора событий 10 на стадии 322 еще раз проверяет вариантные модели в соответствии с процедурами блок-схемы 400. В случае изменения каких-либо данных блок администратора событий 10 выполняет подробный анализ с целью определить, требуется ли выгрузить какие-либо загруженные в настоящий момент вариантные модели и загрузить какие-либо вновь активированные вариантные модели, как описано в связи с описанием блок-схем 400 и 500 на фиг. 9 и 10 соответственно.

Далее на стадии 324 блок администратора событий 10 проверяет специальные действия. Например, если средство использования вспомогательной программы было активировано для считывания информации из базы данных, а такой информации не существует, на блок администратора событий 10 будет возвращен результирующий код. С этим результирующим кодом может быть связано специальное действие, имеющее целью задать следующий текущий объект как идентификатор объекта для сообщения, которое сообщит оператору о том, что указанная информация отсутствует в базе данных. Например:
{current_object}.result_code_000010="jump"
{current_object}.result_code_000010.resultobj$=ObjectlD of the message
{ current_object}.result_code_000010.descriptn$="if record is not on file, display message"
Это действие задаст текущий объект как идентификатор объекта, указанный в переменной {current_object}:
result_code_000010.resultobj$.

В этом случае стадия 326 будет пропущена и управление перейдет на стадию 314.

Если проверка условия (условий) для текущего объекта, выполненная на стадии 314, показала несоблюдение этого условия или, если на стадии 324 специальные действия еще не задали текущий объект, то будет выполнена логика стадии 326. Если блок администратора событий 10 в данный момент времени обрабатывает список пре-процессов для родительского объекта, то в качестве следующего объекта в списке пре-процессов задается текущий объект. В случае, если пре-процессов для текущего объекта больше нет, то текущий объект задается как родительский объект. Поскольку существование объекта, подлежащего выполнению, означает, что процедура не завершена, на стадии 328 управление возвращается на стадию 314.

Если блок администратора событий 10 в данный момент времени обрабатывает родительский объект, то выполняется проверка всех пост-процессов для данного объекта (то есть {current_object}.postprocs$). В случае, если пост-процессов для текущего объекта нет, то блок администратора событий 10 задает текущий объект как следующий объект в списке родительских объектов (lvsequence$). Выполняется проверка, связаны ли какие-либо пре-процессы с данным объектом. Если да, то текущий объект задается как первый объект в списке пре-процессов (то есть {current_object}.preprocs$(1,32)). Если нет, то текущий объект остается следующим родительским объектом. Если блок администратора событий 10 в данный момент времени обрабатывает родительский объект и если с указанным родительским объектом связаны какие-либо пост-процессы, то текущий объект будет задан как первый из этих пост-процессов. Если блок администратора событий 10 в данный момент времени обрабатывает пост-процессы и не осталось ни одного пост-процесса для выполнения, то текущий объект задается как следующий родительский объект, который проверяется на предмет наличия пре-процессов (как описано выше). Если в какой-либо момент времени пост-процесс возвращает положительный результирующий код, то есть с ним не связаны никакие специальные действия (условное обозначение 324 на фиг. 8), то текущий объект задается как текущий объект родительского объекта. Затем этот объект проверяется на предмет наличия пре-процессов. Если какие-либо пре-процессы существуют, то текущий объект задается как первый пре-процесс. И снова, существование текущего объекта означает, что тестирование на стадии 328, выполнен ли процесс, даст отрицательный ответ, таким образом, управление возвращается на стадию 314.

Если на стадии 326 отсутствуют объекты, подлежащие выполнению, или, если на стадии 324 специальное действие ведет к команде выхода из блока администратора событий 10, то на стадии 328 будет дана положительная оценка и на стадии 330 будет осуществлен выход из блока администратора событий 10. Сопроводительный файл, который собирает информацию о модели на стадии выполнения, содержит таблицу всех условий, которые активируют все вариантные модели. Эту таблицу обновляют все вариантные модели, которые зарегистрированы для образцовой модели. Вариантные модели регистрируются для образцовой модели в ходе процедуры регистрации, когда оператор применяет вспомогательную программу для разработки модели того типа, который описан в связи с описанием фиг. 6 и 6А.

Указанная управляющая таблица имеет следующий формат:
LVRTEM.VAR_TABLE$ это - список оценок условий для каждой переменной
LVRTEM. VARIATIONS$ это - список имен переменных, которые соответствуют lvrtem.var_table$
Например, для данной образцовой модели (не показана) в следующих условиях могут применяться три вариантные модели:
Вариантная модель 'variant1':COUNTRY$="US"
Вариантная модель 'variant2':COUNTRY$="CA"
Вариантная модель 'variant3':CLIENT$="ACME"
Параметры для каждого из условий, используемые для активации вариантной модели, хранятся в переменной lvrtem.var table. Это - местодержатель для каждого условия, используемого для всех вариантов. В приведенном примере используются три условия, следовательно, в таблице вариантов имеется три местодержателя.

Для того чтобы активировать variant1, должно быть выполнено условие СОUNТRY$= "US"(представлено значением"1"), положение COUNTRY$="CA" должно быть ложным (представлено значением "0"), а положение CLIENT$="ACME" может быть как истинным, так и ложным, поскольку эта переменная не используется для активации variant1 (представлено значением "0").

Таблица вариантов для variant1 выглядит следующим образом:
lvrtem.var_table$="100"
Для того чтобы активировать variant2, условие COUNTRY$="US" должно быть ложным (представлено значением "0"), положение COUNTRY$="CA" должно быть истинным (представлено значением "1"), а положение CLIENT$="ACME" может быть как истинным, так и ложным, поскольку эта переменная не используется для активации variant2 (представлено значением "0").

Таблица вариантов для variant2 выглядит следующим образом:
lvrtem.var_table$="010"
Для того чтобы активировать variant3, условие COUNTRY$="US" может быть истинным или ложным, поскольку эта переменная не
используется для активации variant3 (представлено значением "0"), положение COUNTRY$="CA" может быть истинным или ложным, поскольку эта переменная не используется для активации variant3 (представлено значением "0"), а положение CLIENT$="ACME" должно быть истинным (представлено значением "1").

Таблица вариантов для variant3 выглядит следующим образом:
lvrtem.var_table$="001"
Таблица вариантов используется для того, чтобы знать, какие варианты могут быть использованы. Таблица вариантов собирает вместе все таблицы условий и выглядит следующим образом:
lvrtem.var_table$="100"+"010"+"001"
или
lvrtem.var_table$="100010001"
Список вариантных моделей хранится в переменной lvrtem. variations. Последовательность вариантов такая же, как последовательность в таблице условий. Например:
lvrtem. variations$="variant1 variant2 variant3"
Условия, которые необходимо проверить, чтобы увидеть, какие из вариантов являются активными, хранятся в переменной Ivrtem. var_check. Порядок условий соответствует порядку величин в таблице условий. Например:
lvrtem.var_check$="(COUNTRY$="US")+(COUNTRY$="CA")+(CLIENT$="ACM E")"
На этапе выполнения задается переменная, которая сравнивается с таблицей вариантов, при этом можно узнать, какой из вариантов применен. Переменная задается с помощью lvrtem.var_check и текущего состояния переменной в блоке памяти. Ниже это показано на примере.

Принимая во внимание, что на этапе выполнения COUNTRY$="US" и CLIENT$= "ACME", будет создана следующая рабочая таблица:
lvrtem.varcurrent$=str(lvrtem.var_check$)
Таким образом, оцениваются содержащиеся в блоке памяти переменные путем сравнения с таблицей вариантов:
(COUNTRY$="US") - истинно - представлено параметром "1"
(COUNTRY$="CA") - ложно - представлено параметром "0"
(CLIENT$="ACME") - истинно - представлено параметром "1"
На основе чего получаем следующую рабочую таблицу:
lvrtem.varcurrent$="101"
Эта рабочая таблица сравнивается с каждой из таблиц для данной модели, хранящихся в lvrtem.var_table$.

Известно, что длина текущей рабочей таблицы составляет три символа, поэтому проверка таблицы вариантов осуществляется блоками из трех символов:
сравните:
AND (lvrtem.var_table$, lvrtem.varcurrent$(1,3)) истинно, следовательно, первый вариант в lvrtem.variations(variant1) неактивен,
сравните:
AND (lvrtem. var_table$, lvrtem.varcurrent$(4,3)) ложно, следовательно, второй вариант в lvrtem.variations(variant2) неактивен,
сравните:
AND (lvrtem.var_table$, lvrtem.varcurrent$(4,3)) истинно, следовательно, третий вариант в lvrtem.variations(variant3) активен.

Если в этом примере "единицы" в таблице вариантов lvrtem.var_table совпадают с "единицами" в соответствующих положениях рабочей таблицы вариантов lvrtem.varcurrent$, вариант считается активным.

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

Гибкая база данных содержит сектор базового файла, представляющий собой обычный файл базы данных. В обычной базе данных все записи базового файла имеют одинаковое количество полей, при этом каждое поле имеет одинаковые характеристики для всего набора записей. В гибкой базе данных это называется базовой записью. На фиг. 11 приведены наглядные примеры базового файла и базовой записи для гибкой базы данных.

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

После того, как базовый файл определен в словаре данных 12 (фиг. 1), к описанию логических файлов могут добавляться наборы вариантов. Эта операция осуществляется через поддержку словаря данных. На фиг. 13А, 13В и 13С показаны стадии, используемые при определении нового набора вариантов. Каждому набору вариантов в словаре данных 12 присваивается идентификатор. Для показанных на фиг. 12 и описанных ниже аборов вариантов идентификаторы составляют соответственно "0001" и"0002". Каждый набор вариантов содержит список полей, а также атрибуты каждого из таких полей. Кроме того, каждый набор вариантов может иметь условие, связанное с этим набором. Это условие определяет базовые записи, к которым применим данный набор вариантов. Если с набором вариантов не связано никакое из условий, то этот набор вариантов применим ко всем базовым записям.

Каждое условие определяет список полей из базовой записи, и значения каждого из них должны определять применимость набора вариантов. Например, если в базовой записи содержится поле, озаглавленное "клиент" ("client"), то набор вариантов может содержать условие, указывающее, что данный набор вариантов применим только, когда поле "клиент" содержит значение "BENJAM".

На фиг. 11 и 12 представлен пример базового файла и набора вариантов. На фиг. 11 базовый файл соответствует логическому файлу "sam_client", в котором хранятся имена и адреса клиентов и доступ в который можно получить, обратившись к имени таблицы исходных данных "sam_dbclient", соответствующей таблицам баз данных/файлу 126 на фиг. 3. Базовая запись базового файла содержит пять полей: клиент, имя, страна, улица и город, каждое из которых имеет свое собственное описание, тип и размер. На фиг. 12 приведены два примера наборов вариантов, соответствующих логическому файлу "sam_client", показанному на фиг. 11, и подключенных к нему. Первый пример - набор вариантов 0001, которому соответствует описание "Информация по Канаде". Условие применения такого набора вариантов требует, чтобы имя поля базовой записи "страна" имело значение "СА", что означает "Канада". При соблюдении указанного условия базовая запись включает не только пять полей, приведенных на фиг. 11 для базовой записи, но также два дополнительных поля: "postal_cd" (содержащее шестизначный индекс) и "province" (содержащее двузначный код провинции). Другими словами, данный набор вариантов относится ко всем базовым записям, соответствующим указанным условиям, дополняющим записи набора вариантов, связанные с данным набором вариантов. Второй пример - набор вариантов на фиг. 12 идентифицируется номером 0002 и имеет описание "Информация по США". Условие применения данного набора вариантов требует, чтобы имя поля базовой записи "страна" имело значение "US". При соблюдении указанного условия базовая запись расширяется и включает в себя два новых поля: "zip_code" (содержащее индекс США) и код штата (содержащее двузначный код штата США или его сокращение). На этом примере показана способность гибкой базы данных расширяться с созданием новых полей при различных информационных условиях.

Все данные набора вариантов хранятся в файле, сопровождающем базовый файл. Такие сопроводительные файлы характеризуются прозрачной поддержкой (и создаются по мере необходимости) со стороны контроллера доступа к базам данных 24, 30 (фиг. 1). Первичный ключ для каждого сопроводительного файла идентичен первичному ключу базового файла, поскольку для каждой записи набора вариантов, которая относится к данному набору вариантов, поддерживается соотношение один к одному относительно всех базовых записей.

DBAC 24, 30 использует небольшую таблицу, которую называют блоком рабочей карты наборов вариантов (УРТМ) для определения, какой из наборов вариантов применим на этапе выполнения. Блок рабочей карты наборов вариантов DBAC 24, 30 представляет собой такую же структуру, как и рабочая таблица вариантов модели блока администратора событий 10, описанная выше в связи с описанием фиг. 5.

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

В данном примере все коды оценки представлены в двоичной форме, где используется только одна цифра 1.

Таблица выражения для этапа выполнения будет следующей:
(COUNTRY$="US")+(COUNTRY$="CA")+(CLIENT$="ACME")
В примере примем, что в блоке памяти после базовой записи хранятся следующие данные:
CLIENT = "ACME"
COUNTRY = "US"
С помощью таблицы кода оценки получим коды оценки с учетом существующих данных и подставим полученные таким образом коды в таблицу выражений для этапа выполнения:
(COUNTRY$="US")+(COUNTRY$="CA")+(CLIENT$="ACME"),
получим код оценки этапа выполнения: "101". Чтобы представить фактическую математическую операцию в двоичных кодах:
позиция 1: COUNTRY$="US" - ИСТИННО, представлено как "1"
позиция 2: COUNTRY$="CA" - ЛОЖНО, представлено как "О"
в результате получим: "101".

Если одно из слагаемых в таблице выражения отсутствует - например, здесь страна не Канада (СА) - код оценки приравнивается к нулю, то есть 0. Поскольку оценка COUNTRY="CA" - второе условие, оценка этого условия хранится на второй позиции двоичного выходного параметра, 101.

Результирующий код оценки этапа выполнения сравнивается с табл.2 (см. в конце описания), при этом демонстрируется соответствие между кодом оценки и вариантами, которые становятся активными с учетом данного кода. Активными вариантами называются те варианты, которые имеют "1" в одних и тех же позициях кода оценки этапа выполнения.

Для каждого логического файла существует одна такая таблица. Наборы вариантов могут существовать в одном из двух состояний: активном или неактивном. Вновь созданный набор вариантов неактивен до тех пор, пока его в явной форме не сделают активным. Когда набор вариантов становится активным, информация об этом наборе вариантов добавляется в VRTM, таким образом, чтобы DBAC 24, 30 знал о существовании данного набора вариантов и использовал его в соответствующих случаях. Когда набор вариантов становится неактивным, информация об этом наборе вариантов удаляется из VRTM, таким образом, чтобы DBAC 24, 30 больше не знал о существовании данного набора вариантов и, следовательно, ничего с этим набором не делал.

В VRTM хранятся следующие блоки информации:
1) Список условий полей (CFL)
Список всех полей, которые включены во все условия набора вариантов. Этот список используется для очень быстрого создания цепочки, в которой содержатся текущие величины для всех полей, включенных в условия набора вариантов. Созданная цепочка называется последовательностью величин условий (CVS).

2) Список групп условий (CGL)
Группа последовательностей представляет возможные значения данных или конфигурации. На этапе выполнения CVS по очереди сравнивается с каждой из конфигураций. Если CVS соответствует конфигурации, положение конфигурации в CGL используется как указатель в списке групп вариантов (см. ниже).

3) Список групп вариантов (VGL)
Список групп номеров наборов вариантов. Просмотр этого списка с указателем CGL, который совпадает с CVS, дает список наборов вариантов, применимых к базовой записи, хранящихся в данный момент в блоке памяти.

VRTM может также включать в себя прочую внутреннюю служебную информацию и информацию о состоянии.

Перед тем, как DBAC 24, 30 сможет выполнить какую-либо функцию для какого-либо логического файла, он должен получить доступ к словарю данных 12. DBAC 24, 30 использует информацию из словаря данных 12 для поиска логических файлов и их физических источников данных. При активации DBAC 24, 30 для выполнения запроса на логический файл, DBAC 24, 30 открывает словарь данных 12 для модуля данного логического файла, если указанный словарь данных 12 еще не открыт. Как только базовый словарь данных открывается, DBAC 24,30 проверяет регистр вариантов и блок рабочей карты наборов вариантов. Описанный выше процесс открытия словаря данных показан на фиг. 15.

Процесс считывания записей из гибкой базы данных осуществляется следующим образом: На этапе выполнения DBAC 24, 30 считывает базовую запись из базового файла. После выполнения этой операции он выполняет поиск в блоке рабочей карты наборов вариантов с целью определить, какой из наборов вариантов применить. На фиг. 16А и 16В показаны стадии, которые DBAC 24, 30 использует для выполнения этой задачи. Если существуют применимые наборы вариантов, то DBAC 24, 30 считывает данные для каждого набора вариантов из соответствующего сопроводительного файла. Если в соответствующем сопроводительном файле запись не обнаружена, то полям для данного набора вариантов присваивается значение ноль. Это может быть в случае, если базовые записи уже существовали до того, как был добавлен набор вариантов.

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

Процесс внесения записей в гибкую базу данных осуществляется следующим образом: На этапе выполнения DBAC 24, 30 ищет в блоке рабочей карты наборов вариантов применимые наборы вариантов в соответствии с фиг. 16А и 16В. Затем DBAC 24,30 записывает данные набора вариантов в соответствующие сопроводительные файлы, затем записывает данные базовой записи в базовом файле. Если какие-либо наборы вариантов, которые были применимы во время считывания записи, во время повторного считывания записи стали неприменимыми, DBAC 24, 30 удалит указанные устаревшие данные набора вариантов из соответствующих сопроводительных файлов.

Запись в гибкой базе данных может быть удалена с помощью следующей процедуры: на этапе выполнения DBAC 24, 30 считывает и блокирует записи, подлежащие удалению, и определяет, какие наборы вариантов, если есть, применимы к базовой записи в соответствии с фиг. 16А и 16В. Эти данные набора вариантов удаляются, удаляется также базовая запись.

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

В варианте осуществления настоящего изобретения, представленном на фиг. 13А, может быть дано описание набора вариантов в соответствии с процедурой 560, которая начинается со стадии 562. Сначала на стадии 564 задается логический файл. Затем на стадии 566 вводится описание набора вариантов вместе с комментариями, которые добавляются на стадии 568. Согласно фиг. 13В на стадии 570 выполняется тестирование с целью определить, нужно ли указывать условие для данного набора вариантов. Если да, то на стадии 572 вводится поле из базовой записи, подлежащее проверке на соблюдение данного условия. Также, на стадии 574 вводится значение, которое должно находиться в этом поле, чтобы данное условие было соблюдено. Затем на стадии 574 осуществляется проверка, существуют ли какие-либо еще поля условий. Если да, процедура возвращается на стадию 572. Если нет или если на стадии 570 не требуется указывать никаких условий, процедура переходит на стадию 578, фиг. 13С. На стадии 578 вводится информация поля для следующего поля, подлежащего включению в существующий набор вариантов. Затем на стадии 580 осуществляется проверка, требуется ли включать какие-либо еще поля. Если да, процедура возвращается на стадию 578. Если нет, то на стадии 582 сохраняется описание набора вариантов и процедура 560 завершается на стадии 584.

Перед тем, как DBAC 24, 30 сможет выполнить какую-либо функцию для какого-либо логического файла, он должен получить доступ к словарю данных 12. DBAC 24, 30 использует информацию из словаря данных 12 для поиска логических файлов и их физических источников данных. При активации DBAC 24, 30 для выполнения запроса на логический файл DBAC 24, 30 открывает словарь данных для модуля данного логического файла, если указанный словарь данных 12 еще не открыт. Как только базовый словарь данных открывается, DBAC 24, 30 проверяет регистр вариантов и блок рабочей карты наборов вариантов, как показано на фиг. 14.

Обратимся к процедуре 600, показанной на фиг. 14; после начала 602 на стадии 604 открывается файл регистра вариантов. Далее на стадии 606 осуществляется проверка, существует ли такой файл. Если да, процедура 600 на стадии 608 открывает рабочую карту вариантов. Затем на стадии 610 осуществляется проверка, существует ли такой блок рабочей карты вариантов. Если да, то на стадии 612 устанавливается метка, указывающая, что для данного модуля существуют активные варианты. В случае, если тестирование на стадиях 606 или 610 не прошло, процедура 600 завершается на стадии 614.

Перед тем, как можно будет сделать логический файл доступным для считывания или записи, его нужно сначала открыть. Как только логический файл открывается, DBAC 24, 30 немедленно загружает в блок памяти рабочую карту наборов вариантов, как показано на фиг. 15. Согласно фиг. 15, файл может быть открыт в соответствии с процедурой 620, начиная со стадии 622. На стадии 624 определяется, существуют ли какие-либо активные варианты для данного логического файла. Если да, то на стадии 626 считывается запись в блоке рабочей карты наборов вариантов, связанная с указанным логическим файлом. Если, как определено на стадии 628, была обнаружена запись, то на стадии 630 рабочая карта наборов вариантов для данного файла записывается в блок памяти. Если на стадии 628 записей не обнаружено или если на стадии 624 не обнаружено факта существования каких-либо активных вариантов для данного логического файла, процедура останавливается на стадии 632.

На этапе выполнения DBAC 24,30 считывает базовую запись из базового файла. После этого он осуществляет поиск в блоке рабочей карты наборов вариантов для определения применимых наборов вариантов. На описанных ниже фиг. 16А и 16В приводятся примеры стадий, с помощью которых DBAC 24, 30 может выполнить указанную задачу.

В случае, если существуют применимые наборы вариантов, DBAC 24, 30 считывает данные для каждого набора вариантов из соответствующего сопроводительного файла. Если в соответствующем сопроводительном файле запись обнаружена не будет, полям для данного варианта будет присвоено нулевое значение. Это будет в случае, если базовые записи уже существовали до добавления набора вариантов.

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

На этапе выполнения DBAC 24, 30 осуществляет поиск в блоке рабочей карты наборов вариантов для определения применимых наборов вариантов. На описанных ниже фиг. 16А и 16В приводится пример указанного процесса. Данные набора вариантов затем записываются в соответствующие сопроводительные файлы и данные базовой записи вносятся в базовый файл.

В случае, если какие-либо наборы вариантов, применимые во время считывания записи, стали неприменимы при ее повторной записи, то DBAC 24, 30 удаляет указанные устаревшие данные набора вариантов из соответствующих сопроводительных файлов.

На этапе выполнения DBAC 24, 30 считывает и блокирует подлежащие удалению записи и определяет наборы вариантов, если есть, применимые к данной базовой записи, как показано в примерах на фиг. 16А и 16В. Данные из набора вариантов удаляются, а затем удаляется и сама базовая запись.

Обратимся теперь к фиг. 16А, на котором приведен пример вышеописанной процедуры 640. После старта на этапе 642 процедура 640 стирает список вариантов, который относится к стадии 644. Затем на стадии 646 она вызывает из блока памяти рабочую карту наборов вариантов для текущего файла. Если процедура обнаруживает на стадии 648 рабочую карту наборов вариантов для текущего файла, то на стадии 650 создается текущий набор вариантов (CVS) для базовой записи. CVS представляет собой оценку условий текущего битового массива на этапе выполнения, используемую для получения информации о том, какие варианты являются применимыми. CVS аналогичен описанному выше lvrtem.varcurrent, однако в данном примере он называется lvdbac.varcurrent. Другими словами, CVS является параметром текущих данных, который проверяется по таблице вариантов для получения информации о том, какой вариант применим в настоящий момент. Далее на стадии 652 текущий CGL (список групп условий) устанавливается как первый элемент CGL. CGL аналогичен описанному выше lvrtem.var table, однако в данном примере он называется Ivdbac.varJable. CVS проверяется поданной таблице для получения информации о том, какие варианты применимы.

Обратимся теперь к фиг. 16В, на стадии 654 производится сравнение между CVS и текущим элементом CGL. Если они совпадают, что определяется на стадии 656, то на стадии 658 в список применимых вариантов добавляется элемент CGL (список групп условий). Если они не совпадают, что определяется на стадии 656, то на стадии 660 выполняется проверка с целью определить, существуют ли еще какие-либо элементы CGL. Если да, то на стадии 662 текущий элемент CGL определяется как следующий элемент CGL и процедура возвращается на стадию 654. Если на стадии 660 элементов CGL больше не найдено, то и процедура возвращается на стадию 664. Если на стадии 648 фиг. 16А не найден блок рабочей карты наборов вариантов, то для данного логического файла отсутствуют активные на данный момент варианты. В этом случае процедура также прекращается на стадии 664.

Описанный выше в связи с описанием фиг. 1 расширенный набор инструментов DBAC 24, 30 имеет несколько точек ввода. Каждая точка ввода соответствует функции, предлагаемой DBAC 24, 30, выполнение которой контроллером DBAC 24, 30 может активировать блок администратора событий 10. В одном из вариантов осуществления настоящего изобретения DBAC 24, 30 имеет десять точек ввода, примеры логики каждой из этих точек по очереди описаны ниже.

ФУНКЦИЯ: СЧИТЫВАТЬ
Выполнение функции СЧИТЫВАТЬ 1200 начинается с инициализации и подтверждения правильности параметров 1205, 1208. Затем функция СЧИТЫВАТЬ запрашивает, открыты ли еще точки входа 1210. Если точки входа открыты, процедура СЧИТЫВАТЬ запрашивает, совпадает ли имя логического файла в текущем запросе СЧИТЫВАТЬ с именем логического файла, открытого на данный момент на точке входа 1215. Если да, то процедура СЧИТЫВАТЬ продолжится, в противном случае процедура выйдет из операции СЧИТЫВАТЬ, указав ошибку 1218. Если обнаружено, что точки входа еще не открыты, то процедура СЧИТЫВАТЬ открывает файл, открывает и считывает словарь данных 12 в соответствии с необходимостью 1220. Если процедура открытия 1225 завершилась успешно, то процедура СЧИТЫВАТЬ продолжится, в противном случае процедура выйдет из операции СЧИТЫВАТЬ, указав ошибку 1228. Если на блок администратора событий 10 поступит запрос на создание из общих данных 1230 первичного ключа подлежащей считыванию записи, то этот ключ будет создан из общих данных 1235 и, если создание ключа успешно завершится 1240, процедура СЧИТЫВАТЬ продолжится. Если создание ключа не завершится успешно, то процедура выйдет из операции СЧИТЫВАТЬ, указав ошибку 1242. Если ранее блок администратора событий 10 не собирался создавать первичный ключ записи и считывать его из общих данных 1230, то операция СЧИТЫВАТЬ просто будет продолжена. Если до этого момента не поступила команда выхода, то операция СЧИТЫВАТЬ считает информацию из базовой записи с диска 1245. Если запись существует 1250, то операция СЧИТЫВАТЬ будет продолжена; в противном случае она выдаст индикатор "такой записи нет" 1255 и продолжит работу. Если считывание не было выполнено по причине, отличной от "такой записи нет" 1260, то процедура выйдет из операции СЧИТЫВАТЬ, указав ошибку 1262. Если считывание не будет прервано, оно продолжится. Будет проверен блок рабочей карты наборов вариантов 1265 и, если существуют наборы вариантов данных, которые применимы к записи 1270, то данные варианта будут считаны с диска 1275. Если таких наборов вариантов данных не существует, то считывание продолжится. В случае, если установлен индикатор "такой записи нет" 1280, процедура СЧИТЫВАТЬ будет продолжена; однако, если такой индикатор не установлен, процедура СЧИТЫВАТЬ считает с диска 1285 любой походящий большой двоичный объект или данные поля из блока памяти. После завершения указанного процесса процедура выходит 1290 из функции СЧИТЫВАТЬ, выдавая сообщение либо об успешном выполнении, либо "такой записи нет". На фиг. 17А и 17В в форме таблицы показаны описанные выше стадии.

ФУНКЦИЯ: ИЗВЛЕЧЬ
Выполнение функции ИЗВЛЕЧЬ 1300 начинается с инициализации и подтверждения правильности параметров 1305, 1308. Затем функция ИЗВЛЕЧЬ запрашивает, открыты ли еще точки входа 1310. Если точки входа открыты, ИЗВЛЕЧЬ запрашивает, совпадает ли имя логического файла в текущем запросе ИЗВЛЕЧЬ с именем логического файла, открытого на данный момент на точке входа 1315. Если да, то процедура ИЗВЛЕЧЬ продолжится, в противном случае процедура выйдет из операции ИЗВЛЕЧЬ 1318, указав ошибку. Если обнаружено, что точки входа еще не открыты, то процедура ИЗВЛЕЧЬ открывает файл, открывает и считывает словарь данных 12 в соответствии с необходимостью 1320. Если процедура открытия 1325 завершилась успешно, то процедура ИЗВЛЕЧЬ продолжится, в противном случае процедура выйдет из операции ИЗВЛЕЧЬ 1328, указав ошибку. Если на блок администратора событий 10 поступит запрос на создание из общих данных 1330 первичного ключа подлежащей считыванию записи, то этот ключ будет создан из общих данных 1335 и, если создание ключа успешно завершится 1340, процедура ИЗВЛЕЧЬ продолжится. Если создание ключа не завершится успешно, то процедура выйдет из операции ИЗВЛЕЧЬ, указав ошибку 1342. Если ранее блок администратора событий 10 не собирался создавать первичный ключ записи и считывать его из общих данных 1330, то операция ИЗВЛЕЧЬ просто будет продолжена. Если до этого момента не поступила команда выхода, то операция ИЗВЛЕЧЬ считает информацию из базовой записи с диска 1345. Если запись существует 1350, то операция ИЗВЛЕЧЬ будет продолжена; в противном случае она выдаст индикатор "такой записи нет" 1355 и продолжит работу. Если считывание не было выполнено по причине, отличной от "такой записи нет" 1360, то процедура выйдет из операции ИЗВЛЕЧЬ, указав ошибку 1362. Если считывание не будет прервано, оно продолжится. Будет проверен блок рабочей карты наборов вариантов 1365 и, если существуют наборы вариантов данных, которые применимы к записи 1370, то данные варианта будут считаны с диска 1375. Если таких наборов вариантов данных не существует, то процедура ИЗВЛЕЧЬ продолжится. В случае, если установлен индикатор "такой записи нет" 1380, процедура ИЗВЛЕЧЬ будет продолжена; однако, если такой индикатор не установлен, процедура ИЗВЛЕЧЬ считает с диска 1385 любой походящий большой двоичный объект или данные поля из блока памяти. После завершения указанного процесса процедура выходит 1390 из функции ИЗВЛЕЧЬ, выдавая сообщение либо об успешном выполнении, либо "такой записи нет".

Различие между операциями ИЗВЛЕЧЬ и СЧИТЫВАТЬ состоит в том, что операция ИЗВЛЕЧЬ блокирует данные для целей ЗАПИСИ. В многопользовательских приложениях одинаковые данные могут одновременно запрашиваться различными операциями. Во избежание повреждения базы данных все данные, подлежащие обновлению, ИЗВЛЕКАЮТСЯ (блокируются) в первую очередь. Если в момент поступления запроса ИЗВЛЕЧЬ данные уже ИЗВЛЕЧЕНЫ (заблокированы), то DBAC 24, 30 будет ждать, пока данные будут разблокированы, после чего продолжит выполнение процедуры. Это осуществляется выдачей повторного запроса на процедуру ИЗВЛЕЧЬ через 1 с. Оператору выводится сообщение, предупреждающее его об указанной ситуации. Затем оператор может прервать запрос ИЗВЛЕЧЬ, после чего на блок администратора событий 10 направляется специальный результирующий код.

ФУНКЦИЯ: ПРОВЕРИТЬ КЛЮЧ
Выполнение функции ПРОВЕРИТЬ КЛЮЧ 1400 начинается с инициализации и подтверждения правильности параметров 1405, 1408. Затем функция ПРОВЕРИТЬ КЛЮЧ запрашивает, открыты ли еще точки входа 1410. Если точки входа открыты, процедура ПРОВЕРИТЬ КЛЮЧ запрашивает, совпадает ли имя логического файла в текущем запросе ПРОВЕРИТЬ КЛЮЧ, с именем логического файла, открытого на данный момент на точке входа 1415. Если да, то процедура ПРОВЕРИТЬ КЛЮЧ продолжится, в противном случае процедура выйдет из операции ПРОВЕРИТЬ КЛЮЧ 1418, указав ошибку. Если обнаружено, что точки входа еще не открыты, то процедура ПРОВЕРИТЬ КЛЮЧ открывает файл, открывает и считывает словарь данных 12 в соответствии с необходимостью 1420. Если процедура открытия 1425 завершилась успешно, то процедура ПРОВЕРИТЬ КЛЮЧ продолжится, в противном случае процедура выйдет из операции ПРОВЕРИТЬ КЛЮЧ 1428, указав ошибку. Если на блок администратора событий 10 поступит запрос на создание из общих данных 1430 первичного ключа подлежащей считыванию записи, то этот ключ будет создан из общих данных 1435 и, если создание ключа успешно завершится 1440, процедура ПРОВЕРИТЬ КЛЮЧ продолжится. Если создание ключа не завершится успешно, то процедура выйдет из операции ПРОВЕРИТЬ КЛЮЧ 1442, указав ошибку. Если ранее блок администратора событий 10 не собирался создавать первичный ключ записи и считывать его из общих данных, то операция ПРОВЕРИТЬ КЛЮЧ просто будет продолжена. Если до этого момента не поступила команда выхода, то операция ПРОВЕРИТЬ КЛЮЧ считает информацию из базовой записи с диска 1445 с помощью этого ключа. Если запись существует 1450, то операция ПРОВЕРИТЬ КЛЮЧ будет продолжена; в противном случае она выдаст индикатор "такой записи нет" и продолжит работу 1460.

ФУНКЦИЯ: СОЗДАТЬ КЛЮЧ
Выполнение функции СОЗДАТЬ КЛЮЧ 1500 начинается с инициализации и подтверждения правильности параметров 1505, 1508. Затем функция СОЗДАТЬ КЛЮЧ запрашивает, открыты ли еще точки входа 1510. Если точки входа открыты, процедура СОЗДАТЬ КЛЮЧ запрашивает, совпадает ли имя логического файла в текущем запросе СОЗДАТЬ КЛЮЧ, с именем логического файла, открытого на данный момент на точке входа 1515. Если да, то процедура СОЗДАТЬ КЛЮЧ продолжится, в противном случае процедура выйдет из операции СОЗДАТЬ КЛЮЧ 1518, указав ошибку. Если обнаружено, что точки входа еще не открыты, то процедура СОЗДАТЬ КЛЮЧ открывает файл, открывает и считывает словарь данных 12 в соответствии с необходимостью 1520. Если процедура открытия 1525 завершилась успешно, то процедура СОЗДАТЬ КЛЮЧ продолжится, в противном случае процедура выйдет из операции СОЗДАТЬ КЛЮЧ, указав ошибку 1528. Затем процедура СОЗДАТЬ КЛЮЧ создает ключ из общих данных 1530. Если создание ключа успешно завершится 1535, то процедура выйдет из операции СОЗДАТЬ КЛЮЧ 1540, сообщив об успешном завершении. Если, с другой стороны, ключ создан не будет, то процедура выйдет из функции СОЗДАТЬ КЛЮЧ 1540, сообщив об ошибке.

ФУНКЦИЯ: ЗАПИСАТЬ
Выполнение функции ЗАПИСАТЬ 1600 начинается с инициализации и подтверждения правильности параметров 1605, 1608. Затем функция ЗАПИСАТЬ запрашивает, открыты ли еще точки входа 1610. Если точки входа открыты, процедура ЗАПИСАТЬ запрашивает, совпадает ли имя логического файла в текущем запросе ЗАПИСАТЬ с именем логического файла, открытого на данный момент на точке входа 1615. Если да, то процедура ЗАПИСАТЬ продолжится, в противном случае процедура выйдет из операции ЗАПИСАТЬ, указав ошибку 1618. Если обнаружено, что точки входа еще не открыты, то процедура ЗАПИСАТЬ открывает файл, открывает и считывает словарь данных 12 в соответствии с необходимостью 1620. Если процедура открытия 1625 завершилась успешно, то процедура ЗАПИСАТЬ продолжится, в противном случае процедура выйдет из операции ЗАПИСАТЬ 1628, указав ошибку. Если блок администратора событий 10 выдаст запрос на создание из общих данных 1630 первичного ключа записи, то функция ЗАПИСАТЬ попытается это сделать 1635. Если создание ключа успешно завершится 1640, процедура ЗАПИСАТЬ продолжится, в противном случае процедура выйдет из операции ЗАПИСАТЬ, указав ошибку 1642. Если, однако, блок администратора событий 10 не выдавал запрос на создание первичного ключа записи из общих данных 1630, то процедура ЗАПИСАТЬ продолжится. В случае, если существует ненулевой первичный ключ 1645, то функция ЗАПИСАТЬ продолжит работу, в противном случае процедура выйдет из операции ЗАПИСАТЬ, указав ошибку 1648. Если функция ЗАПИСАТЬ продолжит работу, то она установит блокировку записи для логического файла 1650. Затем, если она переписывает извлеченную на данный момент запись на данную точку входа 1655, то функция ЗАПИСАТЬ продолжит работу. Если нет, то выполняется проверка существования указанной записи 1660. Если запись существует, то функция ЗАПИСАТЬ снимает блокировку записи и выходит с указанием ошибки 1665. Если такой записи не существует, функция ЗАПИСАТЬ продолжит работу. Если функция ЗАПИСАТЬ продолжит работу, то она получит список расширений, которые в данный момент применимы к текущей записи 1670. Эта функция присваивает значения полям программы 1675. Она записывает любой походящий большой двоичный объект или данные поля из блока памяти. Функция ЗАПИСАТЬ также записывает данные базовой записи на диск 1685. Затем она проверяет, существуют ли какие-либо расширения, которые были применимы при извлечении записи, но стали неприменимыми на данный момент 1690. Если да, то функция ЗАПИСАТЬ удаляет их 1692, в противном случае она продолжает работу, снимая блокировку записи и выходя из процедуры 1695.

ФУНКЦИЯ: УДАЛИТЬ
Выполнение функции УДАЛИТЬ 1700 начинается с инициализации и подтверждения правильности параметров 1705, 1708. Затем функция УДАЛИТЬ запрашивает, открыты ли еще точки входа 1710. Если точки входа открыты, УДАЛИТЬ запрашивает, совпадает ли имя логического файла в текущем запросе УДАЛИТЬ с именем логического файла, открытого на данный момент на точке входа 1715. Если да, то процедура УДАЛИТЬ продолжится, в противном случае процедура выйдет из операции УДАЛИТЬ 1718, указав ошибку. Если обнаружено, что точки входа еще не открыты, то процедура УДАЛИТЬ открывает файл, открывает и считывает словарь данных 12 в соответствии с необходимостью 1720. Если процедура открытия 1725 завершилась успешно, то процедура УДАЛИТЬ продолжится, в противном случае процедура выйдет из операции УДАЛИТЬ, указав ошибку 1728. Если блок администратора событий 10 выдаст запрос на создание записи из общих данных 1730 первичного ключа, то функция УДАЛИТЬ попытается это сделать 1735. Если создание ключа успешно завершится 1740, процедура УДАЛИТЬ продолжится. Если создание ключа не завершится успешно, то процедура выйдет из операции УДАЛИТЬ 1742, указав ошибку. Если, однако, блок администратора событий 10 не запрашивал создание первичного ключа записи из общих данных, то операция УДАЛИТЬ будет продолжена. Если функция УДАЛИТЬ продолжит работу, то она проверит, удаляет ли она извлеченную на данный момент запись из существующей точки входа 1745. Если да, то функция УДАЛИТЬ продолжит работу; если нет, то функция УДАЛИТЬ извлечет данные базовой записи 1750. Если извлечение пройдет успешно 1755, то функция УДАЛИТЬ продолжит работу. Если нет, то она прервет работу, указав ошибку 1758. Если функция УДАЛИТЬ продолжит работу, то она удалит данные базовой записи с диска 1760, удалит все соответствующие наборы данных с расширениями с диска 1765 и удалит любой походящий большой двоичный объект или данные поля из блока памяти с диска 1770, а затем выйдет из операции УДАЛИТЬ 1775.

ФУНКЦИЯ: ЗАКРЫТЬ
Функция ЗАКРЫТЬ 1800 после инициализации и подтверждения правильности параметров 1805, 1808 запрашивает у блока администратора событий 10, закрыты ли все точки входа 1810. Если да, то функция ЗАКРЫТЬ извлекает общий список открытых точек входа 1815, в противном случае она продолжает работу, 1820 на основе списка точек входа, представленного блоком администратора событий 10. Для каждой точки входа в списке, полученном на предыдущей стадии, функция ЗАКРЫТЬ закрывает физический файл с базовой записью, закрывает все применимые физические файлы набора расширений, стирает всю сохраненную информацию о состоянии, связанную с указанными точками ввода 1825 и выходит из 1830 процедуры, сообщая о ее успешном завершении.

ФУНКЦИЯ: ОТКЛЮЧИТЬ
Функция ОТКЛЮЧИТЬ 1850 после инициализации и подтверждения правильности параметров 1855, 1858 активирует функцию ЗАКРЫТЬ и запрашивает у нее закрытие ВСЕХ точек входа 1860. Затем функция ОТКЛЮЧИТЬ закрывает все открытые словари данных 1865 и стирает всю находящуюся в кэш-памяти информацию 1870 о словарях данных и выходит 1875 из процедуры, сообщая о ее успешном завершении.

ФУНКЦИЯ: ПОЛУЧИТЬ КЛЮЧ
Функция ПОЛУЧИТЬ КЛЮЧ 1900 инициализируется и подтверждает правильность параметров 1905, 1908 и запрашивает, открыты ли еще точки ввода 1910. Если да, функция ПОЛУЧИТЬ КЛЮЧ запрашивает, была ли последней операцией на данной точке ввода успешно завершившейся операцией ИЗВЛЕЧЬ 1915. Если да, то функция ПОЛУЧИТЬ КЛЮЧ извлекает текущий ключ 1920. Если нет, то функция ПОЛУЧИТЬ КЛЮЧ ищет следующий ключ 1925. Если попытки поиска следующего ключа завершается успешно 1930, то функция ПОЛУЧИТЬ КЛЮЧ выходит 1935 из процедуры, сообщая о ее успешном завершении. В противном случае или, если последней операцией на данной точке ввода не была успешно завершившаяся операция извлечения, то функция ПОЛУЧИТЬ КЛЮЧ выходит 1940, 1942 из процедуры, сообщая об ошибке.

ФУНКЦИЯ: ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ
Функция ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ 1950 инициализируется и подтверждает правильность параметров 1955, 1958 и запрашивает, открыты ли еще точки ввода 1960. Если да, функция ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ осуществляет поиск первого ключа 1965. Если поиск первого ключа завершается успешно 1970, то функция ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ выходит 1975 из процедуры, сообщая о ее успешном завершении, в противном случае функция ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ выходит 1980 из процедуры, сообщая об ошибке. Если обнаружено, что точка входа еще не была открыта, то функция ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ выходит 1985 из процедуры, сообщая об ошибке.

Некоторые другие функции, а именно ПОЛУЧИТЬ ПРЕДЫДУЩИЙ КЛЮЧ, ПОЛУЧИТЬ ТЕКУЩИЙ КЛЮЧ, ПОЛУЧИТЬ СЛЕДУЮЩИЙ КЛЮЧ, практически идентичны функции ПОЛУЧИТЬ ПЕРВЫЙ КЛЮЧ, но отличаются ключом, который эти функции возвращают.

Одним из преимуществ настоящего изобретения является его способность работать с существующей программой. "Существующей программой" называют прикладную программу, существующую до реализации настоящего изобретения, которую необходимо адаптировать к работе в среде блока администратора событий/модель наряду с моделями, которые были специально разработаны с использованием настоящего изобретения.

Для адаптации существующей программы она конвертируется в форму, доступную для DBAC 24, 30. Чтобы начать преобразование существующей программы в гибридную существующую программу (существующую программу, обращения которой к моделям и методам совместимы с блоком администратора событий 10), все доступы к базам данных заменяются на связи с DBAC 24, 30. Проверка вариантов заменяется обращениями к "предварительной записи проверки правильности файлов и элементов" на основе предварительно скомпилированных банков данных для сегментов словаря данных 12. Запись в файл сопровождается единичным доступом к DBAC 24, 30 с использованием списка файлов, скомпилированного с помощью программ тестирования правильности. Все средства ввода и вывода для предоставления информации преобразуются под использование пользовательских средств ввода-вывода 26. Программа также преобразуется таким образом, чтобы можно было использовать словарь данных 12. Информация об использовании файлов (то есть о записи в файлы, считывания из файлов, извлечении и удалении) помещается в словарь данных 12. Переменные существующей программы переименовываются в соответствии с идентификациями символов, используемыми в словаре данных 12, например, 32-разрядными идентификациями. Ссылки на то, где (например, программа/строка) и как (например, оценка, печать (маскирование переменных), конкатенация, перенос, переключение, ввод, обновление). В процессе преобразования существующей программы в ней допускаются только изменения, связанные с исправлением ошибок; не допускается добавление новой логики.

Создается существующая техническая программа (библиотека) в файле логических объектов, которую может использовать блок администратора событий 10. "Переходные объекты", которые создаются во время перехода со существующей программы в программу, совместимую с подходом к блоку администратору событий 10, могут быть связаны со существующей программой с созданием "гибридных существующих программ". Связь действует через использование "шлюзов". Как описано выше, шлюзы помещаются в существующие программы в промежутках между операторами программы, как описано выше в связи с описанием процесса преобразования существующих программ. Учитывая, что в соответствии с вариантом осуществления настоящего изобретения к существующей программе не может быть добавлена новая логика, изменения в данной программе, включающие в себя новую логику, должны быть активированы за счет вставки шлюза, что позволит подключить или отключить указанную новую логику. Новая логика внедряется посредством моделей и/или методов. Ниже приведен пример условного шлюза к логике, отформатированного для использования с блоком администратора событий 10:
nnnnn DPCU-123456; Perform
"Get_list_of_active Gates";
IF ACTIVE_GATES > 0 THEN Perform "Gate_control"
Вызов "Get_list_of_active_Gates" создаст список всех шлюзов (или управляемой шлюзами логики), которые являются истинными для текущего пользователя; такая оценка включит в себя все общедоступные, а также тестовые объекты, которые данный пользователь зарегистрирует для применения. В случае, когда для продукта приемлема модификация логики, объект просто делается общедоступным, при этом не требуется внесение изменений в приложения.

Описанный выше подход позволяет постоянно осуществлять анализ и "исправлять" гибридные существующие программы. Например, с помощью такого подхода в гибридные существующие программы можно вносить следующие изменения:
- изменения словаря данных 12 для внесения исправлений;
- можно создавать списки маскирования переменных;
- можно осуществить преобразования, обеспечивающие преобразование даты 2000 года;
- можно изменять единицы измерения времени;
- можно заменять существующие маски;
- можно обращаться к возможным надпечаткам (например, на измененных отчетах).

Кроме того, можно вносить следующие изменения для гибридных существующих программ:
1. Можно добавлять, обходить или задавать по умолчанию поля ввода и связанную с ними логику либо с помощью шлюзов, либо иными средствами.

2. К существующим записям файла можно добавлять новые поля:
a) с использованием возможностей гибкой базы данных (описана в связи с описанием функции DBAC 24, 30);
b) можно удалять поля в существующих записях файла, например, устаревшим полям по умолчанию DBAC 24, 30 должен присваивать какое-либо значение, эти поля будут удаляться не немедленно, а позже, за счет использования возможностей гибкой базы данных.

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

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

Реферат

Изобретение относится к компьютерным устройствам, в частности к компьютерным устройствам для разработки и выполнения прикладных компьютерных программ. Техническим результатом является возможность внесения таких изменений для гибридных существующих программ, как добавление, обход или задание по умолчанию полей ввода и связанную с ними логику, причем новые поля, операции записи, извлечения и другие операции могут добавляться даже во время тестирования. Устройство содержит процессор, блок памяти, носитель данных, блок администратора событий. 6 з.п. ф-лы, 2 табл., 39 ил.

Формула

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

2. Устройство по п. 1, отличающееся тем, что зарегистрированными моделями являются только модели, не содержащие ссылок на методы, имеющие возможность активирования других методов.

3. Устройство по п. 1, отличающееся тем, что секторы моделей разбиты на секторы образцовых и вариантных моделей.

4. Устройство по п. 3, отличающееся тем, что секторы вариантных моделей являются носителями данных, по крайней мере, одного условия, а блок администратора событий связан с секторами вариантных моделей с возможностью выполнения названного условия.

5. Устройство по п. 4, отличающееся тем, что блок администратора событий выполнен с возможностью проверки наличия вариантной модели для данной образцовой модели при активации образцовой модели, поиска данной модели при наличии вариантной модели, проверки наличия условий для найденной вариантной модели и выполнения данной вариантной модели при наличии условий для найденной вариантной модели.

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

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

Патенты аналоги

Авторы

БЕННЕТ Джеймс (CA)

КЛАРК Метью (CA)

МАКГУЙРК Фред (CA)

МЕЙВИЗ Уолтер (CA)

BENNET DZHEJMS

KLARK MET JU

MAKGUJRK FRED

MEJVIZ UOLTER

BENNET DZHEJMS

KLARK MET'JU

MAKGUJRK FRED

MEJVIZ UOLTER

Патентообладатели

MEJVIZ INTEHNEHSHNL SOFTVEHA I

MEJVIZ INTEHNEHSHNL SOFTVEHA, INK.

Заявители

МЕЙВИЗ ИНТЭНЭШНЛ СОФТВЭА, ИНК. (CA)

MEJVIZ INTEHNEHSHNL SOFTVEHA I

MEJVIZ INTEHNEHSHNL SOFTVEHA, INK.

СПК: G06F8/10 G06F8/20

Публикация: 2003-08-20

Дата подачи заявки: 1997-12-12

РОССТИП

Поиск по товарам

Добавить свой товар

Сообщества

Товары

Участники

Патенты

Запросов

Поставщикам

О сервисе

Блогерам

Помощь