Система обработки информации и способ ее эксплуатации

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

 

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

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

В классическом способе действуют, как правило, следующим образом.

1. Моделирование процессов.

2. Идентификация необходимых для процессов данных.

3. Объединение и постановка в соотношение всех данных.

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

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

Эта задача решается посредством признаков независимых пунктов формулы.

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

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

1. Идентификация самостоятельных предметов или абстрактных единиц, которые отличаются наружу едиными данными и единым характером (идентификация объектов).

2. Определение данных и образцов характера этих объектов.

3. Определение процессов в качестве интерактивности между объектами.

Объектно-ориентированные действия имеют при этом те преимущества, что

- объекты относительно просто идентифицировать, когда они относятся к реальным предметам (не всегда справедливо для абстрактных объектов);

- объекты являются, как правило, меньшими, более обозримыми единицами, чем процессы;

- объекты обладают, как правило, более длительной достоверностью, чем процессы;

- за счет совместно используемых объектов разные процессы имеют более высокую интеграцию.

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

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

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

В одном предпочтительном выполнении изобретения представления для подключенных систем образуют из КОМ посредством операций проекция и отбор.

Посредством проекции осуществляют выбор того, какие элементы в виде классов, атрибутов, методов, отношений КОМ содержатся в представлении.

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

Согласно изобретению предусмотрено, что соответствующее представление в ЦУС определяет элементы КОМ, которым известна подключенная система, причем представление описывают

- классами с их атрибутами и методами (включая интерфейс), критериями отбора;

- отношениями;

- правилами согласованности.

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

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

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

В целом, для каждой подключенной к ЦУС системы установлена собственная категория классов. При этом каждая категория классов может содержать, в свою очередь, две категории классов для мастер- и клиент-представлений.

Специальная категория классов КОМ разделена на несколько, образованных по определенным критериям подкатегорий. Категории классов содержат:

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

- по меньшей мере, одну диаграмму классов, на которой отображают содержащиеся в представлении классы;

- к каждой операции спецификацию сигнатуры этого метода путем указания структур объектов.

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

На чертежах:

фиг.1 изображает систему обработки информации на основе ЦУС;

фиг.2 - иерархию категорий классов в объектной модели ЦУС;

фиг.3 - интерфейс представления;

фиг.4 - древовидную структуру по фиг.3;

фиг.5 - структуру данных сообщения;

фиг.6 - корректированное сообщение со старыми и новыми значениями.

Как показано на фиг.1, центральный сервер ЦУС 1 данных служит центральным устройством связи между техническими приложениями, которые представлены в виде мастер-систем 3 и/или клиент-систем 2. За счет использования ЦУС 1 становится возможным осуществление связи между этими приложениями с помощью единых способов на основе унифицированного представления (View) данных. Каждая система 2; 3 приложения требует лишь одного интерфейса с ЦУС 1. Больше не требуется разрабатывать собственный интерфейс между каждыми двумя связываемыми системами. Благодаря этому существенно сокращаются затраты на разработку интерфейсов. ЦУС 1 не является системой приложения и не выполняет специальных функций, не представляет собой непосредственного пользовательского интерфейса и не получает специальных данных. Специальные функции, пользовательские интерфейсы и хранение специальных данных происходят в отдельных системах 2; 3 приложения. ЦУС 1 осуществляет считывающий доступ к массивам данных систем приложения и предоставляет услуги, посредством которых системы приложения могут осуществлять доступ ко всем известным ЦУС массивам данных всех подключенных систем приложения. Поскольку многие из специальных данных обрабатываются только в соответствующей специфической системе приложения, только часть массива данных, как правило, становится общеизвестной через ЦУС 1, а именно та часть, которая требуется также другим системам приложения для постановки их задач. Сумму всех становящихся доступными через ЦУС 1 массивов данных описывают в общей концептуальной объектной модели (КОМ) 4 ЦУС 1.

Услуги ЦУС 1 и доступ к ним одинаковы для всех подключенных систем 2; 3. Для каждой системы, однако, соответствующие специфические услуги записывают в особом представлении в концептуальной объектной модели (КОМ) 4 ЦУС 1. Это специфическое представление (View) должно быть соответственно известно системе и ЦУС 1 и устанавливается отдельно для каждой системы. Каждая подключенная система может выполнять по отношению к ЦУС 1 две разные функции: мастер-системы 3 и/или клиент-системы 2.

Мастер-система 3 предоставляет ЦУС 1 определенную в соответствующем мастер-представлении 6 часть своего массива данных. Кроме того, мастер-системы 3 сообщают в ЦУС 1 об изменениях в собственном массиве данных. Клиент-система 2 использует предоставленные ЦУС 1 возможности для доступа к определенным в клиент-представлении 5 данным. Сообщения об изменениях данных в содержащемся в клиент-представлении 5 массиве данных могут быть выбраны клиент-системой 2 у ЦУС1.

За счет устранения связи между мастер-представлением 6 и клиент-представлением 5 возможно, что определенные изменения в мастер-представлениях 6 не будут оказывать влияния на клиент-представления 5. Это, в частности, тот случай, когда ответственность за массив данных переходит с одной мастер-системы 3 на другую. В распоряжении подключенных мастер-систем 3 и клиент-систем 2 имеются за счет ЦУС 1 два механизма связи: доступ к данным и сообщения.

Услуга ЦУС 1 по доступу к данным обеспечивает клиент-системам 2 доступ к определенным в ЦУС 1 массивам данных. Результирующий из этого доступ к ответственным за нужные данные мастер-системам 3 не виден клиент-системам 2, т.е. клиент-системы 2 не знают, каким мастер-системам 3 принадлежат затребованные данные.

Посредством услуги передачи сообщений ЦУС 1 сообщают об изменениях в массиве данных мастер-системы 3. ЦУС 1 предоставляет затем эти изменения соответствующим клиент-системам 2.

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

Таблица 1. Содержание представлений в ЦУС
	Услуга доступа к данным	Услуга передачи сообщений
Клиент-представление	Какие данные может запрашивать клиент-система	В каких сообщениях об изменениях массива данных заинтересована клиент-система
Мастер-представление	Для каких данных мастер-система обладает приоритетом	0 каких изменениях массива данных сообщается в ЦУС

Ниже поясняются некоторые употребляемые термины в области объектного ориентирования.

Ассоциация

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

Атрибут

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

Has-отношение

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

Класс

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

Категория классов

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

Объектное отношение

Объектное отношение (линк) представляет собой конкретное отношение между объектами. Оно является инстанцией ассоциации.

Объект

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

Наследственное отношение

Наследование представляет собой отношение между классами, причем один класс (суб- или подкласс) разделяет структуру и характер другого класса (супер- или надкласса). Подкласс является специализированным видом надкласса.

На фиг.2 изображены структура объектной модели 10 ЦУС и правила, по которым образуют представления 5, 6 подключенных систем 2; 3.

Объектная модель 10 ЦУС состоит из концептуальной объектной модели (КОМ) 4 и представлений 5, 6 (Views) подключенных систем. Поэтому всю модель разделили на несколько категорий, причем для каждой подключенной к ЦУС системы предусматривают одну категорию 11, 14, 17.

Есть категория ЦУС-КОМ 11, содержащая КОМ 4. Сама КОМ 4 расчленена, в свою очередь, на несколько образованных по специальным критериям подкатегорий 12, 13. Далее подключенные системы, например система А и система В, образуют каждая категорию 14, 17, причем имя категории, которая включает в себя представление подключенной системы в ЦУС 1, получает присвоенный, например, постфикс "View" (например, система A-View).

Каждая подключенная система может выступать по отношению к ЦУС 1 как мастер-система 3 и/или как клиент-система 2. Поэтому в категориях 14, 17 в соответствии с ролью системы используют подкатегории мастер-представление 15 или 18 и клиент-представление 16. Отсюда, например, для объектной модели 10 ЦУС при подключенных системах "системы А" 14 и "система В" 17 возникает показанная на фиг.2 иерархия категорий классов.

Представление 5, 6 (View) в ЦУС 1 определяет элементы КОМ 4, которым известна подключенная система. Его описывают содержащимися в ней

- классами с их атрибутами и методами (включая интерфейс), критериями отбора;

- отношениями;

- правилами согласованности.

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

В клиент-представлении 5 подключенной системы содержатся элементы, для которых система хочет получить из ЦУС информацию.

Представления 5, 6 для подключенных систем не могут быть произвольно образованы из КОМ 4. Разрешены операции проекция и отбор. Другие операции в качестве отбора и проекции невозможны. Например, отсутствует операция соединения, посредством которой несколько классов КОМ 4 отображаются в одном классе клиент-представления 5 ЦУС.

Посредством проекции выбирают, какие элементы КОМ 4 (классы, атрибуты, методы, отношения) содержатся в представлении 5, 6. Все другие элементы КОМ 4 посредством проекции подавляют.

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

В отношении согласованности в ЦУС 1 действуют следующие определения:

- ЦУС 1 исходит из того, что в каждый момент времени данные в пределах мастер-системы 3 являются согласованными.

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

- Атрибуты, необходимые для оценки условий согласованности, должны содержаться в КОМ 4.

- Условия согласованности могут быть определены в клиент-представлениях 5.

- За счет воспроизведения данных посредством ЦУС 1 согласованность этих данных не должна уменьшаться.

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

Как уже сказано, для каждой подключенной к ЦУС 1 системы моделируют собственную категорию классов, которая, в свою очередь, может содержать две категории классов для мастер-представления 6 и клиент-представления 5.

Эти категории содержат:

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

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

- для каждой операции указывают спецификацию сигнатуры этого метода путем указания структур объектов.

За счет отображения этой информации в объектной модели 10 ЦУС становится возможным составление полной документации объектной модели, образующей функциональную часть специальной концепции. Кроме того, с помощью этой информации можно создать файлы конфигурации, используемые в ЦУС-приложении для отображения КОМ 4 в различных представлениях 5, 6.

Ниже устанавливают, как в объектной модели 10 ЦУС отображают оба правила для образования представлений 5, 6 (проекция и отбор) и спецификацию интерфейса операций.

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

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

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

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

Правила согласованности определяются на основе клиент-представления 5. Поэтому правила согласованности в Rose-модели отображают в свойстве "правило согласованности" категории клиент-представления.

ЦУС 1 подготавливает следующие виды услуг (сервисные функции):

- сервисные функции выборки для использования услуги доступа к данным;

- сервисные функции сообщений для использования услуги передачи сообщений.

Все сервисные функции отображают в объектной модели 10, в принципе, как методы. Для этих методов не определяют параметры вызова, они определены имеющимися C-API-функциями.

В сервисных функциях также могут быть указаны критерии отбора. Они оказывают ограничивающее действие на определенные в классах критерии. Их определяют в свойстве "критерий отбора" соответствующего метода. Для выполнения действующих правил по образованию клиент- и мастер-представлений 5, 6 необходимо моделировать методы также в КОМ 4 в соответствующих классах.

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

- Должны использоваться только известные классы, атрибуты и отношения.

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

- Кардинальность отношения определяет, идет ли речь об отдельном объекте (≤1) или о списке объектов (кардинальность >1). Здесь, однако, имеется исключение: Если есть уверенность в том, что за счет оценки критериев отбора при отношении с кардинальностью >1 определяется точно один объект, то тогда это можно изобразить в структуре данных путем указания отдельного объекта.

Имеющиеся в представлении, атрибутизированные ассоциации расшифровывают, как это показано на фиг.3, с использованием Booch-нотации.

Соответствующая древовидная структура показана на фиг.4. От класса А 19 можно с помощью имени линк-класса 21 осуществить навигацию к нему, причем кардинальность отношения со стороны класса В определяет, имеется ли в линк-классе один или несколько объектов. От линк-класса можно затем с помощью ролевого имени (идентифицирующий атрибут В) осуществить навигацию к классу В 20 (фиг.3).

Услуги доступа к данным (сервисные функции выборки) определяют для клиент-систем 2 и мастер-систем 3. Клиент-системы 2 определяют специально необходимые для них сервисные функции выборки, с помощью которых они могут осуществлять доступ к определенным в клиент-представлении данным.

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

Услуги передачи сообщений (сервисные функции сообщений) определяют в пределах объектной модели 10 ЦУС как в мастер-представлениях 6, так и в клиент-представлениях 5. В мастер-представлении 6 определяют сообщения, которые мастер-система 3 передает в ЦУС 1. В клиент-представлении 5 определяют сообщения, которые ЦУС 1 передает клиент-системе 2. Сообщение определяют как метод соответствующего класса.

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

К сообщению относятся следующие указания:

- однозначная идентификация сообщения;

- указание, для какого клиент-представления 5 предназначено сообщение (аргумент "userview"),

- тип сообщения (аргумент "message"),

- момент, в который содержащиеся в сообщении данные достоверны;

- указание, от какой мастер-системы 3 передано сообщение;

- данные о сообщении (в виде структуры данных ЦУС_OEDATA);

- типы сообщений.

Существуют следующие виды типов сообщений:

- New (новый): сопоставим с конструктор-методом класса;

- Update (обновить): сопоставим с "нормальным" методом класса;

- Delete (удалить): сопоставим с деструктор-методом класса.

На фиг.5 изображена основная структура данных сообщения. При обработке сообщения в СМ-компоненте там должны быть считаны данные о сообщении. В структуре данных (функциональный параметр "message_data") содержатся максимум две записи:

- логическое значение "filter" и

- структура "data" данных ЦУС_ОЕОАТА.

Значение "filter" имеется в каждом модифицированном сообщении, передаваемом клиент-системе 2, и содержит значение, которое было получено при обработке правила фильтра. Если у клиента 2 не было определено правило фильтра, то вводят значение TRUE. Результат правила фильтра требуется для обработки сообщений Update со стороны клиента.

Подструктура "data" содержится в каждом сообщении как в сообщениях для клиент-систем 2, так и в сообщениях, передаваемых мастер-системами 3 к ЦУС 1. Конструкция подструктуры зависит от соответствующей спецификации сообщения.

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

Содержание подструктуры "data" зависит от типа сообщения:

- тип сообщения New: "data" содержит данные нового объекта;

- тип сообщения Update: "data" содержит новые данные объекта;

- тип сообщения Delete: "data" содержит данные стираемого объекта.

При спецификации сообщения Update в мастер-представлении 6 можно дополнительно указать, переданы ли также старые значения. Это указание приводят в мастер-представлении 6 в ЦУС-свойстве "Messagedaten Master" соответствующего метода.

При спецификации сообщения Update в клиент-представлении 5 можно дополнительно указать:

- хотела бы клиент-система 2 получить также старые значения и

- заинтересована ли клиент-система 2 во всех старых значениях или только в измененных значениях.

Это указание приводят в клиент-представлении 5 в ЦУС-свойстве "Messagedaten Client" соответствующего метода.

Как показано на фиг.6, в сообщениях Update, в случае наличия, старые значения изображают следующим образом. Вместо собственно значения атрибута в структуре данных находится объект класса "changed". Этот объект имеет атрибуты "new" и "old", включающие в себя соответственно новое или старое значение атрибута.

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

Пример на фиг.6 показывает структуру данных для случая, когда атрибут А класса С был изменен.

Перечень ссылочных позиций

1 - центральный сервер данных (ЦУС)

2 - клиент-система

3 - мастер-система

4 - концептуальная объектная модель (КОМ)

5 - клиент-представление (View)

6 - мастер-представление (View)

7 - доступ к данным

8 - услуга передачи сообщений

10 - объектная модель ЦУС

11 - категория (ЦУС.КОМ)

12 - подкатегория

13 - подкатегория

14 - категория (View)

15 - подкатегория (мастер-представление)

16 - подкатегория (клиент-представление)

17 - категория (View)

18 - подкатегория (мастер-представление)

19 - класс

20 - класс

21 - линк-класс

1. Система обработки информации, включающая в себя центральное устройство связи ЦУС (1) для управления и передачи информации массива данных, по меньшей мере, одну мастер-систему (3) обработки информации, которая через интерфейс связана с ЦУС (1) и по требованию предоставляет в ЦУС (1) информацию, по меньшей мере, одну клиент-систему (2) обработки информации, которая через интерфейс связана с ЦУС (1) и по требованию получает от ЦУС (1) информацию, причем управляемая посредством ЦУС (1) информация описана объектной моделью (10), которая включает в себя концептуальную объектную модель КОМ (4), описывающую весь подготовленный мастер- и клиент-системами (2; 3) массив данных, а также соответствующие подключенным системам и описывающие соответственно услуги по отношению к КОМ (4) представления (5; 6), которые определяют элементы управляемого ЦУС (1) массива данных, известные соответствующим системам (2; 3), отличающаяся тем, что каждая мастер-система (3) предоставляет в ЦУС (1) определенные в соответствующем мастер-представлении (6) элементы своего массива данных, причем в мастер-представлении (6) подключенной мастер-системы (3) содержатся элементы массива данных, для которых система обладает приоритетом данных.

2. Система по п.1, отличающаяся тем, что каждая клиент-система (2) посредством услуги доступа к данным обладает доступом к определенным в соответствующем клиент-представлении (5) данным.

3. Система по п.2, отличающаяся тем, что в клиент-представлении (5) подключенной системы (2) содержатся элементы массива данных, для которых система может запрашивать у ЦУС (1) информацию.

4. Система по п.1, отличающаяся тем, что представления (5; 6) для подключенных систем образуют из КОМ (4) посредством операций проекция и отбор.

5. Система по п.4, отличающаяся тем, что посредством проекции происходит выбор того, какие элементы в виде классов, атрибутов, методов, отношений КОМ (4) содержатся в представлении (5; 6).

6. Система по п.4, отличающаяся тем, что посредством отбора происходит выбор отдельных объектов одного класса.

7. Система по п.4, отличающаяся тем, что отбор возможен только в клиент-представлении (5).

8. Система по п.6, отличающаяся тем, что для класса в качестве критерия отбора определяют правило фильтра, которое определяет, какие объекты содержатся в клиент-представлении (5).

9. Система по п.1, отличающаяся тем, что соответствующее представление (5; 6) в ЦУС (1) определяет элементы КОМ (4), известные подключенной системе (2; 3), причем представление (5; 6) описывают:

классами с их атрибутами и методами (включая интерфейс), критериями отбора;

отношениями;

правилами согласованности.

10. Система по п.1, отличающаяся тем, что подключенным мастер- и клиент-системам (2; 3) предоставляют посредством ЦУС (1), по меньшей мере, два механизма связи в виде услуги доступа к данным и услуги передачи сообщений.

11. Система по п.10, отличающаяся тем, что все подготовленные ЦУС (1) услуги определены в объектной модели как методы.

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

13. Система по п.10, отличающаяся тем, что услуги доступа к данным определены для клиент- и мастер-систем (2; 3).

14. Система по п.1, отличающаяся тем, что клиент-системы (2) определяют необходимые для них услуги доступа к данным, с помощью которых они хотят осуществить доступ к определенным в клиент-представлении (5) данным.

15. Система по п.14, отличающаяся тем, что из требований услуг доступа к данным определяют услуги доступа к данным для мастер-систем (3).

16. Система по п.10, отличающаяся тем, что посредством услуги передачи сообщений в ЦУС (1) сообщают об изменениях в массиве данных мастер-системы (3) и ЦУС (1) предоставляет эти изменения соответствующим клиент-системам (2).

17. Система по любому из п.10 или 16, отличающаяся тем, что услуги передачи сообщений определены в пределах объектной модели (10) ЦУС как в мастер-, так и в клиент-представлении (5; 6).

18. Система по п.1, отличающаяся тем, что для каждой подключенной к ЦУС (1) системы (2; 3) установлена собственная категория классов.

19. Система по п.18, отличающаяся тем, что каждая категория классов сама может содержать, в свою очередь, две категории классов для мастер- и клиент-представлений (5; 6).

20. Система п.18, отличающаяся тем, что категория КОМ (11) классов разделена на несколько образованных по определенным критериям подкатегорий (12; 13).

21. Система по п.18, отличающаяся тем, что категории классов содержат:

классы (с атрибутами и методами) и их отношения, которые видны в соответствующем представлении (5; 6);

по меньшей мере, одну диаграмму классов, на которой отображают содержащиеся в представлении (5; 6) классы;

к каждой операции спецификацию сигнатуры этого метода путем указания структур объектов.

22. Способ обработки информации, отличающийся тем, что обеспечивают центральное устройство связи ЦУС (1) для управления и передачи информации о массиве данных, обеспечивают, по меньшей мере, одну мастер-систему (3) обработки информации, которая через интерфейс связана с ЦУС (1) и по требованию предоставляет в ЦУС (1) информацию, обеспечивают, по меньшей мере, одну клиент-систему (2) обработки информации, которая через интерфейс связана с ЦУС (1) и по требованию получает от ЦУС (1) информацию, причем управляемая посредством ЦУС (1) информация расчленена на объектную модель (10), которая включает в себя концептуальную объектную модель КОМ (4), описывающую весь подготовленный мастер- и клиент-системами (2; 3) массив данных, а также соответствующие подключенным системам и описывающие соответственно услуги по отношению к КОМ (4) представления (5; 6), которые определяют элементы управляемого ЦУС (1) массива данных, известные соответствующим системам (2; 3), отличающийся тем, что каждая мастер-система (3) предоставляет в ЦУС (1) определенные в соответствующем мастер-представлении (6) элементы своего массива данных, причем в мастер-представлении (6) подключенной мастер-системы (3) содержатся элементы массива данных, для которых система обладает приоритетом данных.