CZ306010B6

CZ306010B6 - Systém pro zpracování informací a způsob jeho provozování

Info

Publication number: CZ306010B6
Application number: CZ2002-4204A
Authority: CZ
Inventors: Adrian Ciornei; Achim Klabunde; Wolfgang Stein; Eric Truchet
Original assignee: T-Mobile Deutschland Gmbh
Priority date: 2000-05-23
Filing date: 2001-05-23
Publication date: 2016-06-22
Also published as: DE10025050A1; PL365905A1; EP1285315A2; US20040093606A1; RU2276403C2; CZ20024204A3; WO2001090827A2; WO2001090827A3; EP1285315B1; AU2001265806A1

Abstract

Systém zpracování informací zahrnuje centrální komunikační instanci (1) ZDS ke správě a přesměrování informací datového souboru alespoň jeden Master-systém (3) zpracování informací, který komunikuje přes rozhraní centrální komunikační instancí (1) ZDS a který jí dává na požádání k dispozici informace, alespoň jeden Client-systém (2) zpracování informací, který komunikuje přes rozhraní s centrální komunikační instancí (1) ZDS a na požádání od ní dostává informace, přičemž informace, spravované centrální komunikační instancí (1) ZDS, se popisují objektovým modelem, který zahrnuje koncepční objektový model (4) KOM, který popisuje celý datový soubor, poskytnutý Master- a Client-systémy (2, 3), a připojeným systémům přiřazené pohledy, (Views) popisující právě specifické služby s ohledem na koncepční objektový model (4) KOM, které určují prvky datového souboru, spravovaného centrální komunikační instancí (1) ZDS, které znají příslušné systémy. Způsob provozu systému spočívá z poskytnutí centrální komunikační instance (1) ZDS, poskytnutí alespoň jednoho Master-systému (3) a alespoň jednoho Client-systému (2).

Description

Systém pro zpracování informací a způsob jeho provozování

Oblast techniky

Vynález se týká systému pro zpracování informací a způsobu jeho provozování podle úvodní části nezávislých patentových nároků.

Dosavadní stav techniky

Vynález pochází z oblasti modelování komplexních systémů. Vychází se ze systému pro zpracování informací, se kterým se má provádět výměna dat mezi několika technickými aplikacemi. Podstatný problém při modelování komplexních systémů spočívá v tom, že se má pokrýt dynamický a statický pohled na model. Dynamický pohled na model se přitom zpravidla znázorňuje modely procesu a statický pohled na model pomocí modelů dat.

Klasickým způsobem se zpravidla postupuje následujícím způsobem:

1. Modelování procesů

2. Identifikace dat, potřebných pro procesy

3. Shrnutí a dosazení všech dat do vztahu.

Tento způsob má nevýhodu, že není příliš pružný vůči např. změnám nebo doplnění ve struktuře procesu a dat.

GB 2 319 863 A popisuje takzvaný Groupware-systém, zejména pro intemet-/extranet-aplikace, s velkým počtem Client-aplikaci, které vždy poskytují příslušné pohledy informace. Informace je uložena v centrální objektové databázi společně s procesy, použitelnými na objekty. Je navržený velký počet strojů s mechanismy, aby se nechaly ukládat a nechalo se manipulovat s objekty, uloženými v databázi. Tento systém se muže přednostně používat v počítačových sítích, u kterých se programy zavádějí ze sítě na jednotlivé šitové počítače a tam se provádějí, jako např. JAVA-programy.

Úkol vynálezu spočívá v tom, navrhnout systém pro zpracování informací a způsob jeho provozování, se kterým se zjednodušuje specifikace a vývoj rozhraní mezi technickými aplikacemi.

Podstata vynálezu

Tento úkol se řeší znaky nezávislých patentových nároků.

Systém pro zpracování informací podle vynálezu zahrnuje centrální komunikační instanci (ZDS) ke správě a přesměrování informací datového souboru, minimálně Master-systém pro zpracování informací, který komunikuje přes rozhraní s ZDS, a který poskytuje ZDS na požádání informace, minimálně Client-systém pro zpracování informací, který komunikuje přes rozhraní s ZDS a na požádání dostává od ZDS informace, přičemž informace, spravované ZDS se popisují objektovým modelem, který zahrnuje koncepční objektový model (KOM), který popisuje celkový datový soubor, poskytnutý Master- a Client-systémy, a připojeným systémům přiřazené a právě specifické služby s ohledem na KOM popisující pohledy (Views), které určují prvky datového souboru, spravovaného ZDS, které znají příslušné systémy.

Vynález má za základ objektově orientovaný postup při modelování procesů. Objektově orientovaný postup vypadá následovně:

- 1 CZ 306010 B6

1. Identifikace svébytných předmětů nebo abstraktních jednotek, které se vyznačují směrem ven pomocí jednotných dat a jednotným chováním (objektová identifikace)

2. Definice dat a vzor chování těchto objektů

3. Definice procesů jako interakce mezi objekty.

Objektově orientovaný postup má přitom přednosti, že

- objekty se nechají identifikovat relativně jednoduše, když se vztahují na reálné předměty (neplatí vždy pro abstraktní objekty)

- objekty jsou zpravidla menší, přehlednější jednotky než procesy

- objekty mají zpravidla delší platnost než procesy

- různé procesy mají pomocí společně použitých objektů vyšší integraci.

Objektově orientovaný postup má mimoto tu přednost, že se nechá relativně jednotně používat po všechny fáze procesu vývoje softwaru (odborná koncepce/analýza-DV-koncepce/návrh-impíementace/realizace-provoz/údržba), což není možné u klasického způsobu.

Přednostní provedení a další formy vynálezu jsou uvedené v závislých nárocích.

Každý Master-systém dává přednostně ZDS k dispozici prvky svého datového souboru, definované v příslušném Master-pohledu, přičemž v Master-pohledu připojeného Master-systému jsou obsažené prvky datového souboru, pro které má systém svrchovanost dat.

Každý Client-systém má zároveň přes službu přístupu k datům přistup na data, definovaná v příslušném Client-pohledu, přičemž v Client-pohledu připojeného systému jsou obsažené prvky datového souboru, pro které může systém vyvolat informace od ZDS.

V přednostním provedení vynálezu se tvoří pohledy pro připojené systémy z KOM pomocí operací projekce a selekce. Projekcí se uskutečňuje výběr, které prvky na způsob tříd, atributů, metod, vztahů KOM jsou obsažené v pohledu. Selekcí se uskutečňuje výběr jednotlivých objektů třídy. Selekce je přitom možná jenom v Client-pohledu. Přednostně je pro třídu definováno jako kritérium selekce filtrační pravidlo, které určuje, které objekty jsou obsažené v Client-pohledu.

Podle vynálezu je navrženo, že příslušný pohled na ZDS určuje prvky KOM, které zná připojený systém, přičemž se pohled popisuje pomocí:

-tříd sjejich atributy a metodami (včetně rozhraní) kritérií selekce

- vztahů

- pravidel shodnosti.

Ke komunikaci mezi sebou jsou k dispozici připojeným Master- a Client-systémům pomocí ZDS alespoň dva komunikační mechanismy na způsob služby přístupu k datům a služby hlášení, přičemž všechny služby dané od ZDS k dispozici jsou definované jako metody v objektovém modelu. U služeb se mohou používat kritéria selekce, která dodatečně působí omezeně na kritéria, definovaná u tříd.

-2CZ 306010 B6

Služby přístupu k datům jsou definované jak pro Client-, tak i Master-systémy. Client-systémy k tomu definují pro ně odborně nutné služby přístupu k datům, se kterými mají přístup k datům, definovaným v Client-pohledu. Z požadavků Client-služeb přístupu k datům se potom mohou definovat služby přístupu k datům pro Master-systémy.

Služby hlášení uvnitř ZDS-objektového modelu jsou definované nejenom v Master- ale i v Client-pohledech. Přes služby hlášení se změny v datovém souboru Master-systému hlásí na ZDS, přičemž ZDS dává k dispozici tyto změny příslušných Client-systémů.

Obecně je pro každý systém, připojený k ZDS, zřízená vlastní kategorie třídy. Každá kategorie třídy přitom může sama obsahovat opět dvě kategorie třídy pro Master- a Client-pohledy.

Speciální kategorie třídy KOM je rozdělena na více podkategorií podle určitých kritérií. Kategorie třídy obsahují:

- přesně třídy (s atributy a metodami) a jejich vztahy, které jsou viditelné v příslušném pohledu, - alespoň jeden diagram třídy, ve kterém se znázorňují třídy, obsažené v pohledu,

- ke každé operaci specifikaci signatury této metody pomocí udání objektové struktuiy.

Objasnění výkresů

Vynález bude blíže vysvětlen prostřednictvím konkrétních příkladů provedení znázorněných na výkresech, na kterých představuje obr. 1 přehled systému pro zpracování informací, založeného na ZDS;

obr. 2 znázornění hierarchie kategorií třídy v ZDS-objektovém modelu;

obr. 3 definice rozhraní pohledu;

obr. 4 struktura stromu obrázku 3;

obr. 5 struktura dat zprávy;

obr. 6 znázornění Update-Message se starými a novými hodnotami.

Příklady uskutečnění vynálezu

Jak je znázorněno na obrázku 1, slouží centrální datový server ZDS 1 jako centrální komunikační instance mezi technickými aplikacemi, které se mohou vyskytovat jako Master-systémy 3 a/nebo Client-systémy 2. Použitím ZDS 1 se umožňuje provádět komunikaci mezi těmito aplikacemi jednotnými způsoby na bázi sjednoceného pohledu (View) na data. Každý aplikační systém 2; 3 vyžaduje jenom ještě rozhraní k ZDS L Už není třeba, mezi dvěma komunikujícími systémy vyvíjet vlastní rozhraní. Tím se podstatně zmenšují náklady na vývoj a údržbu pro rozhraní. Vlastní ZDS 1 není žádný aplikační systém ve vlastním smyslu. Neprovádí sám žádné odborné funkce, nenabízí žádné přímé uživatelské rozhrání a neobsahuje sám žádná odborná data. Odborné funkce, uživatelská rozhrání a odborná údržba dat existují v jednotlivých aplikačních systémech 2; 3. ZDS 1 přistupuje ke čtení v datových souborech aplikačních systémů a nabízí služby, pomocí kterých mohou aplikační systémy přistupovat ke všem, ZDS známým, datovým souborům všech připojených aplikačních systémů. Protože mnohá z odborných dat se zpracovávají jen v právě specifických aplikačních systémech, zpravidla se jen část datového souboru činí známým přes ZDS 1, a sice část, která se vyžaduje i jinými aplikačními systémy pro jejich formulaci úlohy. Suma všech datových souboru, ke kterým se nechá přistupovat přes ZDS 1, se popisuje ve společném modelu, koncepčním objektovém modelu (KOM) 4 od ZDS 1.

-3CZ 306010 B6

Služby ZDS 1 a přístup k nim jsou stejné pro všechny připojené systémy 2; 3. Pro každý systém se popisují ale právě specifické služby ve zvláštním pohledu na koncepční objektový model 4 ZDS L Tento specifický pohled (View) musí být vždy znám systému a ZDS 1 a stanovuje se pro každý systém jednotlivě. Každý připojený systém může vzhledem k ZDS 1 vystupovat ve dvou rozdílných rolích: jako Master-systém 3 a/nebo jako Client-systém 2.

Master-systém 3 dává ZDS 1 k dispozici část svého datového souboru, definovanou v příslušném Master-pohledu 6. Master-systémy 3 mimoto uvědomují ZDS 1 o změnách ve vlastním datovém souboru. Client-systém 2 využívá možnosti, dané od ZDS 1 k dispozici, k přístupu k datům, definovaným v Client-View 5. Hlášení o změnách dat do datového souboru, obsaženém v Client-View 5, se mohou vyzvedávat Client-systémem 2 u ZDS T

Pomocí zrušení vazby Master- 6 a Client-View 5 je možné, že určité změny na Master-View 6 nemají žádné účinky na Client-View 5. To je zejména ten případ, že když příslušnost projeden datový soubor přechází od jednoho Master-systému 3 na jiný. Připojeným Master- 3 a Clientsystémům 2 jsou pomocí ZDS 1 k dispozici dva komunikační mechanismy: přístup k datům a hlášení.

Služba ZDS 1 přístupu k datům umožňuje Client-systémům 2 přístup na datové soubory, definované v ZDS 1. Z toho vyplývající přístup na Master-systémy 3, příslušné pro žádaná data, není pro Client-systémy 2 viditelný, tzn. Client-systémy 2 nemají žádnou znalost, ke kterým Mastersystémům 3 požadovaná data patří. Přes službu hlášení se změny v datovém souboru Mastersystému 3 hlásí na ZDS 1. ZDS 1 dává potom tyto změny k dispozici příslušným Client-systémům 2.

Následující tabulka ukazuje, které informace pro službu přístupu k datům a službu hlášení jsou obsažené v Master- a Client-Views:

	služba přístupu k datům	služba hlášení
Clientpohled	která data může Clientsystém prověřovat	o která hlášení o změnách datového souboru se Client-systém zajímá
Masterpohled	pro která data má Master-systém svrchovanost dat	které změny datového souboru se hlásí na ZDS

Tabulka 1: obsahy Views na ZDS

Následně se vysvětluje několik použitých pojmů z oblasti objektové orientace.

Asociace

Asociace je nejobecnější forma vztahu mezi třídami. Popisuje sémantiku a strukturu mnoha objektových vztahů. Kardinalita asociace určuje, kolik objektů tříd, stojících ve vztahu, se podílí na asociaci. Uvedením jmen rolí se popisuje sémantika vztahu, tzn. ve které roli vidí objekty jedné třídy objekty jiné třídy. Když asociace disponuje vlastními atributy, potom se jedná o atributovanou asociaci.

-4CZ 306010 B6

Atribut

Atribut je datový prvek, který je obsažen v každém objektu třídy a v každém objektu může mít individuální hodnotu. Atribut se popisuje svým jménem a svým typem. Identifikované atributy se vyznačují tím, že objekt jednoznačně určují, tzn. neexistuje žádný jiný objekt se stejně identifikovanými atributy.

Has-vztah

Has-vztah nebo agregace je zvláštní forma obecného asociačnímu vztahu. Zúčastněné třídy popisují celek/část-hierarchii tzn. agregace popisuje, jak se něco celého skládá ze svých částí.

Třída

Třída je množství objektů, které mají společnou strukturu a společné chování. Struktura třídy se popisuje pomocí atributů a vztahů k jiným třídám, chování pomocí operací jedné třídy.

Kategorie třídy

Kategorie třídy se používají, aby se rozvrhnul logický model. Kategorie třídy může obsahovat třídy a jiné kategorie třídy. Neobsahuje ale, na rozdíl od třídy, přímo žádné operace nebo stavy modelu.

Objektový vztah

Objektový vztah (Link) je korektní vztah mezi objekty. Je instancí asociace.

Objekt

Objekt je konkrétně existující jednotka, má status, chování a identitu. Každý objekt je exemplář (instance) nějaké třídy. Informace objektu se reprezentuje atributy, jejichž struktura je definována ve třídě. Chování se určuje operacemi, definovanými ve třídě, a je stejné pro všechny objekty třídy.

Vztah odkazu

Odkaz je vztah mezi třídami, přičemž ten dělí třídu (sub- nebo podtřídu), strukturu a chování jiné třídy (super- nebo nadtřída). Podtřída je specializovaný typ nadtřídy.

Obrázek 2 ukazuje výstavbu ZDS-objektového modelu 10 a pravidla, podle kterých se tvoří pohledy 5, 6 připojených systémů 2; 3.

ZDS-objektový model 10 se skládá z koncepčních objektových modelů (KOM) 4 a pohledů 5, 6 (Views) připojených systémů. Proto se celkový model dělí do několika kategorií, přičemž pro každý systém, připojený na ZDS 1, se navrhuje kategorie 11, 14, 17.

Existuje kategorie ZDS-KOM 11, která obsahuje KOM 4. Vlastní KOM 4 je opět členěna na několik podkategorií 12, 13, tvořených podle odborných kritérií. Připojené systémy, např. systém A a systém B, dále tvoří právě kategorii 14, 17, přičemž jméno kategorie, která obsahuje pohled uzavřeného systému na ZDS 1, dostává přiděleno, např. Postfix „View“ (např. systém A-View).

Každý připojený systém může vůči ZDS 1 vystupovat jako Master- 3 a/nebo jako Client-systém 2. Proto se v kategoriích 14, 17 podle role systému zřizují podkategorie Master-View 15 popř. 18

-5CZ 306010 B6 a Client-View 16. Z toho vyplývá např. pro ZDS-objektový model 10 při připojených systémech „Systém A“ 14 a „Systém B“ 17 hierarchie kategorií tříd, ukázaná na obrázku 2.

Pohled 5, 6 (View) na ZDS 1 určuje prvky KOM 4, které zná připojený systém. Popisuje se pomocí v něm obsažených

-tříd sjejich atributy a metodami (včetně rozhraní) kritérií selekce

- vztahů

- pravidel konzistence.

V Master-View 6 připojeného systému jsou obsažené prvky, pro které je systém „Master“, tzn. pro které má systém svrchovanost dat. K tomu se pro každou třídu definuje primární Mastersystém. Tento je příslušný pro identifikující atributy třídy, v mnoha případech i pro všechny jiné atributy. Když jsou ale pro jiné atributy odpovědné další systémy, potom se tyto systémy označují jako sekundární Master-systém. V Master-Views sekundárních Master-systémů jsou vedle „vlastních“ atributů dodatečně obsažené identifikující atributy třídy.

V Client-View 5 připojeného systému jsou obsažené prvky, pro které chce systém dostávat informace od ZDS.

Views 5, 6 pro připojené systémy nemohou být libovolně tvořené z KOM 4. Dovolené jsou operace projekce a selekce. Jiné operace než selekce a projekce nejsou možné! Neexistují např. žádné Join-Operation, pomocí kterých se více tříd KOM 4 zobrazuje na třídu ZDS-Client-Views 5.

Pomocí projekce se vybírá, které prvky (třídy, atributy, metody, vztahy) KOM 4 jsou obsažené v View 5, 6. Všechny ostatní prvky KOM 4 se pomocí projekce potlačují.

Selekce je možná jen v Client-View 5. Pomocí selekce se mohou vybírat jednotlivé objekty třídy. K tomu se pro třídu může jako kritérium selekce udávat filtrační pravidlo, které určuje, které objekty jsou obsažené v Client-View 5. Filtrační pravidla se definují u tříd Client-View 5. Udávají se např. v syntaxi, opřené o SQL-řeč. Jako filtrační atributy se označují atributy, které jsou nutné pro vyhodnocení filtračních pravidel.

Ohledně konzistence v ZDS 1 platí následující definice:

- ZDS 1 vychází z toho, že v každém časovém okamžiku jsou data konzistentní uvnitř Mastersystému 3.

- Podmínky konzistence, které vycházejí přes hranice Master-systému, musí být odborně specifikované.

- Atributy, které jsou nutné k vyhodnocení podmínek konzistence, musí být obsažené v KOM 4.

- Podmínky konzistence mohou být definované v Client Views 5.

- Předáváním dat pomocí ZDS 1 se nesmí konzistence těchto dat zmenšovat.

Pravidla konzistence jsou (na rozdíl od filtračních pravidel) definována na bázi Client-Views 5, tzn. toto odpovídá logické definici, že Client-View 5 musí být v sobě konzistentní. Pokud nejsou

-6CZ 306010 B6 žádná pravidla konzistence definována na Client-Views 5, vychází se z toho, že příslušná data jsou vůči sobě vždy konzistentní. Jako atributy konzistence se označují atributy, které jsou nutné pro vyhodnocení pravidel konzistence. Syntax pravidel konzistence odpovídá syntaxi filtračních pravidel.

Jak je již šíře popsáno nahoře, modeluje se pro každý systém, připojený k ZDS 1, vlastní kategorie třídy, která sama může opět obsahovat dvě kategorie třídy pro Master- 6 a Client-View 5.

Tyto kategorie obsahují:

- přesně třídy (s atributy a metodami) a jejich vztahy, které jsou viditelné v příslušném View, přičemž jména tříd jsou tvořena podle výše uvedených jmenných konvencí,

- alespoň jeden diagram třídy, ve kterém se znázorňují třídy, obsažené ve View,

- ke každé operaci se specifikuje specifikace signatury této metody uvedením objektových struktur.

Vytvořením těchto informací v ZDS-objektovém modelu 10 se stává možným, zhotovit kompletní dokumentaci objektového modelu, která tvoří funkční část odborného konceptu. Mimoto je možné, těmito informacemi vytvořit konfigurační soubory, které se používají v ZDS-aplikaci KOM 4 na různé Views 5, 6.

V následujících úsecích se stanovuje, jak se obě 6 pravidla k tvorbě Views 5, 6 (projekce a selekce) a specifikace rozhraní operací zobrazuje v ZDS-objektovém modelu 10.

Projekce pro třídy a vztahy se uskutečňuje tím, že v kategoriích třídy Views 5, 6 jsou obsažené jen ty třídy a vztahy, které patří k View.

V těchto třídách existují jen ty atributy a operace, které patří k View. Přitom platí, že atributy ve třídách View mají stejné jméno a typ, jako atributy příslušné třídy KOM 4. U operací platí analogicky rovnost jmen a rozhraní.

K prvkům, obsaženým ve View, se mohou View-specifícké popisy udávat v „Documentation“poli příslušného specifikačního dialogu.

Selekce, tzn. dodatečné filtrování, se nenechá v Booch-Notation vyjádřit. V Rose-Modell se proto udávají kritéria selekce v Property „Selektionskriteriu“ třídy, patřící k View.

Pravidla konzistence se definují na bázi Client-View 5. Pravidla konzistence se proto v RoseModell zobrazují v Property „Konsistenregel“ Client-View-kategorie.

Od ZDS 1 se poskytují různé typy služeb (Services):

- Retrieve-Services k využití služby přístupu k datům

- Message-Services k využití služby hlášení.

Všechny Services se zásadně zobrazují jako metody v objektovém modelu 10. Pro tyto metody se nedefinují žádné vyvolávací parametry, tyto jsou definované pomocí existujících C-API-funkcí.

U Services se mohou rovněž udávat kritéria selekce. Působí dodatečně omezujícím způsobem na kritéria, definovaná u tříd. Definují se v Property „Selektionskriterium“ příslušné metody. Aby se vyhovělo platným pravidlům k tvorbě Client- a Master-Views 5, 6, musí se metody také modelovat v KOM 4 na příslušných třídách.

Pro oba typy Services se na rozhraní předávají komplexní struktury stromu. Jejich výstavba se musí ke zhotovení odborného konceptu specificky definovat pro každý Service. Tyto datové struktury se musí nechat zobrazit na příslušný View, tzn.

- Smějí se používat jenom známé třídy, atributy a relace.

- Mohou se tvořit reference na podobjekty z Has-vztahů a asociací, přičemž jméno reference odpovídá jménu Has-vztahu popř. jménu role asociace.

- Kardinalitou vztahu se rozumí, zda se jedná o jediný objekt (kardinalita < 1) nebo o seznam objektů, (kardinalita > 1). Existuje zde ale výjimka:

Když je jisté, že pomocí vyhodnocení kritérií selekce u vztahu s kardinalitou > 1 se přesně poskytl jeden objekt, potom se může toto znázornit v datové struktuře uvedením jediného objektu.

- Ve View existující atributované asociace se ruší, jak je toto znázorněno na obrázku 3 při použití Booch-Notation.

Příslušnou strukturu stromu ukazuje obrázek 4. Od třídy A 19 se může přes jméno třídy Linktřídy 21 k této navigovat, přičemž kardinalita vztahu na straně třídy B určuje, zda od Link-třídy existuje jeden nebo několik objektů. Od Link-třídy se muže potom navigovat přes jméno role (identifikovaný atribut B) k třídě B 20 (obrázek 3).

Služby přístupu k datům (Retrieve-Services) se definují pro Client- 2 a Master-systémy 3. Client-systémy 2 definují Retrieve-Services, se kterými mohou přistupovat k datům, definovaným v Client-View 5. Z požadavků Client-Retrieve-Services se definují Retrieve Services pro Master-systémy 3. To využívá službu přístupu k datům ke zjištění dat, která se požadují Client systémy 2. V objektovém modelu se Retrieve-Services modelují jako metody třídy příslušné třídy.

Služby zpráv (Message-Services) se definují uvnitř ZDS-objektového modelu 10 nejenom v Master- 6 ale i v Client-Views 5. V Master-View 6 se definují zprávy, které Master-Systém 3 posílá na ZDS L V Client-View 5 se definují Messages, které se posílají od ZDS 1 na Clientsystém 2. Message se definuje jako metoda příslušné třídy.

Client-systémy obsahují jen Messages, které jsou pro ně zajímavé, tzn. které se týkají datového souboru příslušného Clients. K tomu se musí při zpracování zohledňovat kritéria selekce.

K Message patří následující údaje:

-jednoznačné Message-Id,

- údaj, pro které Client-View 5 je Message určen (argument „userview“),

- typ Message (argument „message“),

- časový okamžik, ve kterém jsou v Message obsažená data platná,

- údaj, od kterého Master-systému 3 se Message vysílaly a

- data Message (na způsob ZDS OEDATA-datová struktura)

- typy Message.

Existují následující druhy typu Message:

- New: srovnatelný s konstruktor-metodou třídy

- Update: srovnatelný s „normální“ metodou třídy

-8CZ 306010 B6

- Delete: srovnatelný s destruktor-metodou třídy.

Obrázek 5 představuje základní strukturu dat Message. Při zpracování Message na CM-komponenty se tam musí data Message číst. V datové struktuře (funkční parametr „message data“) jsou obsažené maximálně dva zápisy:

- Boolova hodnota „filtr“ a

- ZDS OEDATA-datová struktura „data“.

Hodnota „filtr“ existuje v každé Update-Message, která se vysílá na Client-systém 2, a obsahuje hodnotu, která se zjišťovala při vyhodnocováni filtračních pravidel. Když se u Client 2 nedefinovalo žádné filtrační pravidlo, je zanesena hodnota TRUE. Výsledek filtračního pravidla je zapotřebí pro zpracování Update-Messages na Client-straně.

Podstruktura „data“ je obsažená v každé Message, nejenom v Messages pro Client-systémy 2, ale i v Messages, které se vysílají od Master-systému 3 na ZDS L Výstavba podstruktury je závislá na příslušné specifikaci Message.

V Client-systému 2 odpovídá výstavba „data“ přesně prvkům, které by chtěl obdržet Clientsystém 2. Z požadavků různých Client-systémů 2 pro určitý typ Message třídy vyplývá výstavba příslušné Message v Master-systému 3: jejich „data“-struktura musí být definována tak, že v ní jsou obsažené všechny informace tohoto Master, které patří k této Message.

Obsah podstruktury „data“ je závislý na typu Message:

- typ Message New: „data“ obsahuje data nového objektu.

- typ Message Update: „data“ obsahuje nová data objektu.

- typ Message Delete: „data“ obsahuje data objektu, který je třeba smazat.

Při specifikaci Update-Message v Master-View 6 se může dodatečně udávat, zda se také dodávají staré hodnoty. Tento údaj se udává v Master-View 6 v ZDS-Property „Message data Master“.

U specifikace Update-Message v Client-View 5 se může dodatečně uvádět,

- zda Client-systém 2 může také obdržet staré hodnoty a

- zda Client-systém 2 má zájem o všechny hodnoty nebo jenom o změněné hodnoty.

Tento údaj se udává v Client-View 5 v ZDS-Property „Message data Client“ příslušné metody.

Jak je znázorněno na obrázku 6, znázorňují se v Update-Messages, pokud existují, staré hodnoty následujícím způsobem: místo vlastní hodnoty atributu se v datové struktuře nachází objekt třídy „changed“. Tento objekt má atributy „new“ a „old“, které obsahují novou popř. starou hodnotu atributu.

Třída „changed“ se zvláště definuje pro tento účel. Nepoužívá se sice u definice struktury dat Message, je ale, pokud se dodávají staré hodnoty, obsažena v datové struktuře.

Příklad podle obrázku 6 ukazuje datovou strukturu pro případ, že atribut A třídy C byl změněn:

Claims

PATENTOVÉ NÁROKY

1. Systém pro zpracování informací pro výměnu dat mezi několika technickými systémy aplikací, které mohou vystupovat jako Master-systém (3) pro zpracování informací a/nebo Clientsystém (2) pro zpracování informací, vyznačující se tím, že zahrnuje:

centrální komunikační instanci ZDS (1) ke správě a přesměrování informací datového souboru, alespoň jeden Master-systém (3) pro zpracování informací, který komunikuje přes rozhraní se ZDS (1) a který dává ZDS (1) na požádání k dispozici informace, které jsou uloženy na Mastersystému (3) pro zpracování informací, přičemž každý Master-systém (3) pro zpracování informací poskytuje ZDS (1) prvky datového souboru, definované v příslušném Master-View (6), alespoň jeden Client-systém (2) pro zpracování informací, který komunikuje přes rozhraní se ZDS (1) a na požádání dostává informace od ZDS (1), přičemž zmíněný alespoň jeden Mastersystém (3) pro zpracování informací a zmíněný alespoň jeden Client-systém (2) pro zpracování informací tvoří přes centrální komunikační instanci ZDS navzájem propojený systém, a každý Client-systém (2) pro zpracování informací má přes službu přístupu (7) k datům přístup na data, definovaná v příslušném Client-View (5), přičemž ZDS (1) přistupuje ke čtení v datových souborech Master- a Client-systému (3, 2) pro zpracování informací a nabízí služby, pomocí kterých mohou Master- a Client-systémy (3, 2) pro zpracování informací přistupovat ke všem ZDS (1) známým datovým souborům všech připojených Master- a Client-systémů (3, 2) pro zpracování informací, přičemž informace, spravované ZDS (1), se popisují objektovým modelem (10), který zahrnuje koncepční objektový model KOM (4), který popisuje celý datový soubor, poskytnutý Mastera Client-systémy (2; 3) pro zpracování informací, a popisuje připojeným systémům přiřazené Views (5; 6), které popisují vždy specifické služby s ohledem na KOM (4) a určují prvky datového souboru, spravovaného ZDS (1), které znají příslušné připojené Master- a Client-systémy (2; 3) pro zpracování informací, přičemž Views (5; 6) pro připojené systémy se tvoří z celého datového souboru KOM (4) pomocí operací projekce a selekce, přičemž přes projekci se uskutečňuje výběr, které prvky jsou ve View (5; 6) obsažené ve formě tříd, atributů, metod, vztahů KOM (4), a pomocí selekce se uskutečňuje výběr jednotlivých objektů třídy.
2. Systém pro zpracování informací podle nároku 1, vyznačující se tím, že v Master-View (6) připojeného Master-systému (3) jsou obsažené prvky datového souboru, pro které je Master-systém (3) pro zpracování informací „Master“ a má svrchovanost dat.
3. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že v Client-View (5) připojeného Client-systému (2) pro zpracování informací jsou obsažené prvky datového souboru, pro které může Client-systém (2) pro zpracování informací vyvolat informace ze ZDS (1).
4. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se t í m , že selekce je možná jenom v Client-View (5).
5. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že pro třídu se jako kritérium selekce definuje filtrační pravidlo, které určuje, které objekty jsou obsažené v Client-View (5).
6. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tí m , že příslušný pohled (5; 6) určuje naZDS (1) prvky KOM (4), které zná připo

-10CZ 306010 B6 jeny Master- nebo Client systém (2; 3) pro zpracování informací, přičemž pohled (5; 6) se popisuje pomocí:

-tříd sjejich atributy a metodami (včetně rozhraní) kritérii selekce

- vztahů

- pravidel konzistence.
7. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že připojeným Master- a Client-systémům (2; 3) pro zpracování informací se pomocí ZDS (1) dávají k dispozici alespoň dva komunikační mechanismy v podobě služby přístupu (7) k datům a služby (8) hlášení.
8. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že všechny služby, poskytnuté od ZDS (1), jsou definované jako metody v objektovém modulu.
9. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, žeu služeb se používají kritéria selekce, která působí dodatečně omezujícím způsobem na kritéria, definovaná u tříd.
10. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že služby přístupu (7) k datům jsou definované pro Client- a Master-systémy (2; 3) pro zpracování informací.
11. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že Client-systémy (2) pro zpracování informací definují pro ně odborně nutné služby přístupu (7) k datům, se kterými chtějí přistupovat k datům definovaným v Client-View (5).
12. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že z požadavků Client-služeb přístupu (7) k datům se definují služby přístupu (7) k datům pro Master-systémy (3) pro zpracování informací.
13. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že přes službu (8) hlášení se na ZDS (1) hlásí změny v datovém souboru Master-systému (3) pro zpracování informací a ZDS (1) dává tyto změny k dispozici příslušným Client-systémům (2) pro zpracování informací.
14. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že služby (8) hlášení jsou definované uvnitř ZDS-objektového modelu (10) jak v Master- tak i v Client-View (5; 6).
15. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že pro každý Master- nebo Client-systém (2; 3) pro zpracování informací, připojený na ZDS (1), je zřízena vlastní kategorie třídy.
16. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že každá kategorie třídy sama může opět obsahovat dvě kategorie třídy pro Master- a Client-View (5; 6).

-11 CZ 306010 B6
17. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se tím, že kategorie třídy (11) KOM (4) je rozčleněna na několik podkategorií (12; 13), vytvořených podle určitých kritérií.
18. Systém pro zpracování informací podle některého z předcházejících nároků, vyznačující se t í m , že kategorie třídy obsahují:

- přesně ty třídy (s atributy a metodami) a jejich vztahy, které jsou viditelné v příslušném View (5; 6),

- alespoň diagram třídy, ve kterém se znázorňují třídy, obsažené ve View (5; 6),

- ke každé operaci specifikaci signatury této metody pomocí údaje o objektových strukturách.
19. Způsob provozování systému pro zpracování informací podle některého z předcházejících nároků, vyznačující se:

poskytnutím centrální komunikační instance ZDS (1) ke správě a přesměrování informací datového souboru, poskytnutím alespoň jednoho Master-systému (3) pro zpracování informací, který komunikuje přes rozhraní se ZDS (1) a na požádání dává ZDS (1) k dispozici informace, které jsou uloženy na Master-systému (3) pro zpracování informací, který přes rozhraní komunikuje s ZDS (1), přičemž každý Master-systém (3) pro zpracování informací poskytuje ZDS (1) prvky datového souboru, definované v příslušném Master-View (6), poskytnutí alespoň jednoho Client-systému (2) pro zpracování informací, který komunikuje přes rozhraní se ZDS (1) a na požádání dostává informace od ZDS (1), přičemž zmíněný alespoň jeden Master-systém (3) pro zpracování informací a zmíněný alespoň jeden Client-systém (2) pro zpracování informací tvoří přes centrální komunikační instanci ZDS navzájem propojený systém, a každý Client-systém (2) pro zpracování informací má přes službu přístupu (7) k datům přístup na data, definovaná v příslušném Client-View (5), přičemž ZDS (1) přistupuje ke čtení v datových souborech Master- a Client-systémů (3, 2) pro zpracování informací a nabízí služby, pomocí kterých mohou Master- a Client-systémy (3, 2) pro zpracování informací přistupovat ke všem ZDS (1) známým datovým souborům všech připojených Master- a Client-systémů (3, 2) pro zpracování informací, přičemž informace, spravované ZDS (1), jsou rozčleněné do ZDSobjektového modelu (10), který zahrnuje koncepční objektový model KOM (4), který popisuje celý datový soubor, poskytnutý Master- a Client-systémy (2; 3) pro zpracování informací, a popisuje připojeným systémům přiřazené Views (5; 6), které popisují vždy specifické služby s ohledem na KOM (4), které určují prvky datového souboru spravovaného ZDS (1), které znají příslušné připojené Master- a Client-systémy (2; 3) pro zpracování informací, přičemž Views (5; 6) pro připojené systémy se tvoří z KOM (4) pomocí operací projekce a selekce, přičemž přes projekci se uskutečňuje výběr, které prvky jsou ve View (5; 6) obsažené ve formě tříd, atributů, metod, vztahů KOM (4), a pomocí selekce se uskutečňuje výběr jednotlivých objektů třídy.