WO2001090827A2 - Informationsverarbeitungssystem und verfahren zu dessen betrieb - Google Patents

Informationsverarbeitungssystem und verfahren zu dessen betrieb Download PDF

Info

Publication number
WO2001090827A2
WO2001090827A2 PCT/DE2001/001932 DE0101932W WO0190827A2 WO 2001090827 A2 WO2001090827 A2 WO 2001090827A2 DE 0101932 W DE0101932 W DE 0101932W WO 0190827 A2 WO0190827 A2 WO 0190827A2
Authority
WO
WIPO (PCT)
Prior art keywords
zds
information processing
processing system
client
master
Prior art date
Application number
PCT/DE2001/001932
Other languages
English (en)
French (fr)
Other versions
WO2001090827A3 (de
Inventor
Adrian Ciornei
Achim Klabunde
Wolfgang Stein
Eric Truchet
Original Assignee
Detemobil
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Detemobil filed Critical Detemobil
Priority to AU2001265806A priority Critical patent/AU2001265806A1/en
Priority to EP01943124A priority patent/EP1285315B1/de
Priority to US10/276,987 priority patent/US20040093606A1/en
Priority to PL01365905A priority patent/PL365905A1/xx
Publication of WO2001090827A2 publication Critical patent/WO2001090827A2/de
Publication of WO2001090827A3 publication Critical patent/WO2001090827A3/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B15/00—Systems controlled by a computer
    • G05B15/02—Systems controlled by a computer electric
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data

Definitions

  • the invention relates to an information processing system and a method for its operation according to the preamble of the independent claims.
  • the invention originates from the field of modeling complex systems.
  • the starting point is an information processing system with which a data exchange between several technical applications is to be carried out.
  • the main problem when modeling complex systems is to match the dynamic and the static model view.
  • the dynamic model view is usually represented by process models and the static model view by data models.
  • This method has the disadvantage that it is very inflexible compared to e.g. Changes or additions in the process and data structure is.
  • the object of the invention is to propose an information processing system and a method for its operation, with which a specification and development of the interfaces between the technical applications is simplified.
  • the information processing system comprises a central communication entity (ZDS) for managing and forwarding information from a database, at least one master information processing system which communicates with the ZDS via an interface and provides information to the ZDS on request, at least one client information processing system, which communicates with the ZDS via an interface and receives information from the ZDS on request, whereby the information managed by the ZDS is described by an object model that includes a conceptual object model (KOM) that contains the entire database provided by the master and client systems describes, and the associated systems and the respective specific services with regard to the COM descriptive views (views) that determine the elements of the database managed by the ZDS that the systems in question know.
  • ZDS central communication entity
  • the invention is based on an object-oriented procedure when modeling the processes.
  • the object-oriented procedure looks like this:
  • the object-oriented approach has the advantage that it can be used relatively uniformly across all phases of the software development process (specialist concept / analysis - IT concept / design - implementation / implementation - operation / maintenance), which is not the case with traditional methods ,
  • Each master system preferably provides the ZDS with the elements of its data stock which are defined in an associated master view, the elements of the data stock for which the system has data sovereignty being contained in the master view of a connected master system.
  • each client system has access to the data defined in an associated client view via a data access service, the client view of a connected system containing the elements of the database for which the system can call up information from the ZDS.
  • the views for the connected systems from the COM are formed by the operations projection and selection.
  • the projection is used to select which elements are contained in a view in the form of classes, attributes, methods, relationships of the COM.
  • a selection is used to select individual objects in a class.
  • a selection is only possible in a client view.
  • a filter rule is preferably defined as a selection criterion for a class, which determines which objects are contained in the client view.
  • the respective view of the ZDS determines the elements of the COM that the connected system knows, a view being described by: - classes with their
  • the ZDS provides the connected master and client systems with at least two communication mechanisms in the form of a data access service and a message service, with all the services provided by the ZDS being defined as methods in the object model. Selection criteria can be used for the services, which additionally restrict the criteria defined for the classes.
  • the data access services are defined for both client and master systems.
  • the client systems define the data access services that are technically necessary for them, with which they want to access the data defined in the client view.
  • Data access services for the master systems can then be defined from the requirements of the client data access services.
  • the message services within the ZDS object model are defined in both master and client views. Changes in the database of a master system are reported to the ZDS via the message services, the ZDS making these changes available to the affected client systems.
  • class category In general, a separate class category is set up for each system connected to the ZDS. Each class category can itself contain two class categories for master and client views.
  • the special class category KOM is subdivided into several subcategories based on certain criteria.
  • the class categories include:
  • Figure 1 Overview of a ZDS-based information processing system
  • Figure 2 Representation of the hierarchy of the class categories in the ZDS
  • Figure 3 Definition of the interface of a view
  • Figure 4 Tree structure for Figure 3;
  • Figure 6 Representation of an update message with old and new values.
  • a central data server ZDS 1 serves as a central communication entity between technical applications that can occur as master systems 3 and / or client systems 2.
  • Using the ZDS 1 makes it possible to carry out communication between these applications using standardized procedures based on a unified view of the data.
  • Each application system 2; 3 only needs an interface to the ZDS 1. It is no longer necessary to communicate between two communicating Systems to develop their own interface. This significantly reduces the development and maintenance work for the interfaces.
  • the ZDS 1 itself is not an application system as such. It does not perform any functional functions, does not offer a direct user interface and does not contain any technical data itself. Technical functions, user interfaces and technical data management can be found in the individual application systems 2; 3 instead.
  • the ZDS 1 has read access to the databases of the application systems and offers services through which the application systems can access all the databases of the connected application systems known to the ZDS. Since many of the technical data are only processed in the specific application system, only part of the data is generally made public via ZDS 1, namely the part that is also required by other application systems for their tasks. The sum of all data stocks accessible via the ZDS 1 is described in a common model, the Conceptual Object Model (KOM) 4 of the ZDS 1.
  • KOM Conceptual Object Model
  • ZDS 1 The services of ZDS 1 and access to them are for all connected systems 2; 3 equal. For each system, however, the specific services are described in a special view of the conceptual object model 4 of the ZDS 1. This specific view must be known to the system and the ZDS 1 and is defined individually for each system.
  • Each connected system can act in two different roles compared to the ZDS 1: as a master system 3 and / or as a client system 2.
  • a master system 3 provides the ZDS 1 with the part of its data stock defined in a respective master view 6. In addition, the master systems 3 notify the ZDS 1 of changes in their own database.
  • a client system 2 uses the options provided by the ZDS 1 to access the data defined in a client view 5. Messages about data changes in the data stock contained in the client view 5 can be picked up by the client system 2 from the ZDS 1. By decoupling Master 6 and Client View 5, it is possible that certain changes to Master Views 6 do not affect the Client Views
  • Data is transferred from one master system 3 to another.
  • the ZDS 1 provides the connected master 3 and client systems 2 with two communication mechanisms:
  • the data access service of the ZDS 1 enables the client systems 2 to access the data stocks defined in the ZDS 1.
  • the resulting access to the master systems 3 responsible for the desired data is not visible to the client systems 2, i.e. the client systems 2 have no knowledge of which master systems 3 the requested data belong to.
  • An association is the most general form of a relationship between classes. It describes the semantics and structure of a number of object relationships.
  • the cardinality of the association determines how many objects the related
  • An attribute is a data element that is contained in every object of a class and can have an individual value in each object.
  • An attribute is described by its name and its type.
  • Identifying attributes are characterized by the fact that they uniquely determine an object, i.e. there is no other object with the same identifying
  • the has relationship or aggregation is a special form of the more general association relationship.
  • the classes involved describe a whole sub-hierarchy, i.e. an aggregation describes how something whole is composed of its parts.
  • a class is a set of objects that have a common structure and behavior.
  • the structure of a class is described by the attributes and relationships to other classes, the behavior by the operations of a class. class category
  • Class categories are used to split the logical model.
  • Class category can include classes and other class categories. In contrast to a class, however, it does not directly contain any operations or states of the
  • An object relationship is a concrete relationship between objects. It is an instance of an association.
  • An object is a concrete existing unit, it has a status, a behavior and an identity.
  • Each object is an instance of a class.
  • the information of an object is represented by attributes, the structure of which is defined in the class.
  • the behavior is determined by the operations defined in the class and is the same for all objects in a class.
  • Inheritance is a relationship between classes, with one class (subclass or subclass) sharing the structure and behavior of the other class (superclass or superclass).
  • the subclass is a specialized type of the superclass.
  • FIG. 2 shows the structure of the ZDS object model 10 and the rules according to which the views 5, 6 of the connected systems 2; 3 are formed.
  • the ZDS object model 10 consists of the conceptual object model (KOM) 4 and the views 5, 6 (views) of the connected systems.
  • the overall model was therefore divided into several categories, with a category 11, 14, 17 being provided for each system connected to the ZDS 1.
  • There is a category ZDS-KOM 11 which contains the KOM 4.
  • the COM 4 itself is in turn divided into several subcategories 12, 13, which are based on technical criteria.
  • the connected systems for example system A and system B, each form a category 14, 17, the name of the category which contains the view of the connected system on the ZDS 1 being assigned, for example, the postfix “view” (for example system A -view).
  • Each connected system can act as a master 3 and / or client system 2 compared to the ZDS 1. Therefore, in categories 14, 17, depending on the role of the system, the subcategories Master View 15 or 18 and Client View
  • the view 5, 6 (view) on the ZDS 1 determines the elements of the COM 4 that the connected system knows. It is described by those contained therein
  • the master view 6 of a connected system contains the elements for which the system is the "master", ie for which the system has data sovereignty.
  • a primary master system is defined for each class. This is responsible for the identifying attributes of the class, in many cases also for all other attributes. However, if other systems are responsible for other attributes, then these systems are referred to as the secondary master system.
  • master views of the secondary master systems also contain the identifying attributes of the class.
  • the client view 5 of a connected system contains the elements for which the system wants to receive information from the ZDS.
  • Views 5, 6 for the connected systems cannot be formed arbitrarily from COM 4.
  • the operations projection and selection are allowed. Operations other than selection and projection are not possible! There are e.g. no join operation, by means of which several classes of the KOM 4 are mapped to a class of a ZDS client view 5.
  • a projection is used to select which elements (classes, attributes, methods, relationships) of the KOM 4 are contained in a view 5, 6. All other elements of the KOM 4 are hidden by the projection.
  • a selection is only possible in a client view 5. Individual objects of a class can be selected by a selection. This can be done for a class as
  • Objects are contained in the client view 5.
  • the filter rules are defined for the classes of client view 5. You will e.g. in a syntax based on the SQL language.
  • the ZDS 1 assumes that the data within a master system 3 are consistent at all times.
  • Consistency conditions can be defined in Client Views 5.
  • Consistency rules are defined on the basis of a client view 5, i.e. this corresponds to the logical definition that a client view 5 must be inherently consistent.
  • Consistency attributes are the attributes that are necessary for the evaluation of consistency rules.
  • the syntax of the consistency rules corresponds to the syntax of the filter rules
  • the projection for classes and relationships takes place in that the class categories of views 5, 6 only contain the classes and relationships that belong to the view.
  • view-specific descriptions can be specified in the "Documentation" field of the respective specification dialog.
  • the selection i.e. additional filtering cannot be expressed in Booch notation.
  • the selection criteria are therefore specified in the 'Selection criteria' property of the class belonging to the view.
  • Consistency rules are defined on the basis of a client view 5.
  • the consistency rules in the Rose model are therefore shown in the 'Consistency rule' property of the client view category.
  • ZDS 1 Different types of services are provided by ZDS 1:
  • Selection criteria can also be specified for services. They also restrict the criteria defined for the classes. They are defined in the 'Selection criterion' property of the relevant method. In order to comply with the applicable rules for creating client and master views 5, 6, the methods must also be modeled in the corresponding classes in KOM 4.
  • References to sub-objects can be formed from has relationships and associations, the name of the reference corresponding to the name of the has relationship or the role name of the association.
  • Attributed associations existing in the view are resolved, as is shown in FIG. 3 using the Booch notation.
  • the associated tree structure is shown in FIG. 4. From class A 19, the class name of link class 21 can be used to navigate to it, with the cardinality The relationship on the part of class B determines whether there are one or more objects from the link class. The link class can then be used to navigate to class B 20 via the role name (identifying attribute B) (FIG. 3)
  • Data access services are defined for client 2 and master systems 3.
  • Client systems 2 define the retrieve services that are technically necessary for them, with which they want to access the data defined in the client view 5.
  • retrieve services for the master systems 3 are defined from the requirements of the client retrieve services.
  • the data access service uses this to determine the data requested by the client systems 2.
  • retrieve services are modeled as class methods of the respective class.
  • Message services are defined within the ZDS object model 10 both in master views 6 and in client views 5.
  • the messages that the master system 3 sends to the ZDS 1 are defined in a master view 6.
  • the messages that are sent from the ZDS 1 to the client system 2 are defined in a client view 5.
  • a message is defined as the method of the respective class.
  • Client systems only receive messages that are of interest to them, i.e. that affect the database of the respective client. For this, the selection criteria must be observed during processing.
  • the following information belongs to a message:
  • Figure 5 shows the basic structure of the message data.
  • the data structure (function parameter 'message_data') contains a maximum of two entries:
  • the value 'filter' is present in every update message that is sent to a client system 2 and contains the value that was determined when the filter rule was evaluated. If no filter rule has been defined for client 2, the value TRUE is entered. The result of the filter rule is required for handling update messages on the client side.
  • the 'data' substructure is contained in every message, both in the messages for the client systems 2 and in the messages which are sent from the master systems 3 to the ZDS 1.
  • the structure of the substructure depends on the respective specification of the message.
  • the structure of 'data' corresponds exactly to the elements that the client system 2 would like to receive.
  • the content of the 'data' substructure depends on the message type:
  • 'data' contains the data of the object to be deleted.
  • This information is specified in the client view 5 in the ZDS property 'Messagenaten Client' of the respective method.
  • old values are displayed in update messages as follows: Instead of the actual attribute value, there is an object of the class 'changed' in the data structure. This object has the attributes 'new' and 'old', which contain the new or old attribute value.
  • the 'changed' class is specifically defined for this purpose. Although it is not used when defining the message data structure, it is included in the data structure if the old values are supplied.
  • the example according to FIG. 6 shows the data structure in the event that attribute A of class C was changed:

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Control By Computers (AREA)

Abstract

Die Erfindung betrifft ein Informationsverarbeitungssystem und ein Verfahren zum Betrieb desselben, welches umfasst: eine zentrale Kommunikationsinstanz ZDS zur Verwaltung und Weiterleitung von Informationen eines Datenbestandes, mindestens ein Master-Informationsverarbeitungssystem, welches über eine Schnittstelle mit dem ZDS kommuniziert, und dem ZDS auf Anforderung Informationen zur Verfügung stellt, mindestens ein Client-Informationsverarbeitungssystem, welches über eine Schnittstelle mit dem ZDS kommuniziert und auf Anforderung Informationen vom ZDS erhält, wobei die vom ZDS verwalteten Informationen durch ein Objektmodell beschrieben sind, das ein konzeptionelles Objektmodell KOM umfasst, das den gesamten von den Master- und Client-Systemen bereitgestellten Datenbestand beschreibt, und den angeschlossenen Systemen zugeordnete und die jeweils spezifischen Dienste in bezug auf das KOM beschreibende Sichten (Views), welche die Elemente des vom ZDS verwaltenden Datenbestands bestimmen, die die betreffenden Systeme kennen.

Description

Informationsverarbeitungssystem und Verfahren zu dessen Betrieb
Die Erfindung betrifft ein Informationsverarbeitungssystemen und ein Verfahren zu dessen Betrieb gemäss dem Oberbegriff der unabhängigen Patentansprüche.
Die Erfindung entstammt dem Gebiet der Modellierung komplexer Systeme. Es wird von einem Informationsverarbeitungssystem ausgegangen, mit welchem ein Datenaustausch zwischen mehreren technischen Anwendungen durchgeführt werden soll. Das wesentliche Problem bei der Modellierung komplexer Systeme besteht darin, die dynamische und die statische Modellsicht zur Deckung zu bringen. Die dynamische Modellsicht wird dabei in der Regel durch Prozessmodelle und die statische Modellsicht durch Datenmodelle dargestellt.
Im klassischen Verfahren wird in der Regel folgendermaßen vorgegangen:
1. Modellierung der Prozesse
2. Identifizierung der für die Prozesse benötigten Daten
3. Zusammenfassung und in-Beziehung-Setzung aller Daten
Dieses Verfahren hat den Nachteil, dass es sehr unflexibel gegenüber z.B. Änderungen oder Ergänzungen in der Prozess- und Datenstruktur ist.
Die Aufgabe der Erfindung besteht darin, ein Informationsverarbeitungssystem und ein Verfahren zu dessen Betrieb vorzuschlagen, mit dem eine Spezifikation und Entwicklung der Schnittstellen zwischen den technischen Anwendungen vereinfacht wird.
Diese Aufgabe wird durch die Merkmale der unabhängigen Patentansprüche gelöst. Das erfindungsgemäße Informationsverarbeitungssystem umfasst eine zentrale Kommunikationsinstanz (ZDS) zur Verwaltung und Weiterleitung von Informationen eines Datenbestandes, mindestens ein Master-Informationsverarbeitungssystem, welches über eine Schnittstelle mit dem ZDS kommuniziert, und dem ZDS auf Anforderung Informationen zur Verfügung stellt, mindestens ein Client- Informationsverarbeitungssystem, welches über eine Schnittstelle mit dem ZDS kommuniziert und auf Anforderung Informationen vom ZDS erhält, wobei die vom ZDS verwalteten Informationen durch ein Objektmodell beschrieben sind, das ein konzeptionelles Objektmodell (KOM) umfasst, das den gesamten von den Master- und Client-Systemen bereitgestellten Datenbestand beschreibt, und den angeschlossenen Systemen zugeordnete und die jeweils spezifischen Dienste in bezug auf das KOM beschreibende Sichten (Views), welche die Elemente des vom ZDS verwaltenden Datenbestands bestimmen, die die betreffenden Systeme kennen.
Der Erfindung liegt ein objektorientiertes Vorgehen bei der Modellierung der Prozesse zugrunde. Das objektorientierte Vorgehen sieht folgendermaßen aus:
1. Identifizierung von eigenständigen Gegenständen oder abstrakten Einheiten, die sich nach außen durch einheitliche Daten und ein einheitliches Verhalten auszeichnen (Objektidentifizierung)
2. Definition der Daten und Verhaltensmuster dieser Objekte
3. Definition von Prozessen als Interaktion zwischen Objekten
Das objektorientierte Vorgehen hat dabei die Vorteile, dass
- Objekte sich relativ einfach identifizieren lassen, wenn sie sich auf reale Gegenstände beziehen (gilt nicht immer für abstrakte Objekte)
- Objekte in der Regel kleinere, überschaubarere Einheiten sind als Prozesse
- Objekte in der Regel längere Gültigkeit besitzen als Prozesse
- Unterschiedliche Prozesse durch gemeinsam genutzte Objekte eine höhere Integration aufweisen Darüber hinaus hat das objektorientierte Vorgehen den Vorzug, dass es sich über alle Phasen des Softwareentwicklungsprozesses (Fachkonzeption/Analyse - DV- Konzeption/Entwurf - Implementierung/Realisierung - Betrieb/Wartung) relativ einheitlich anwenden lässt, was bei den klassischen Verfahren nicht der Fall ist.
Vorteilhafte Ausführungsformen und Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Vorzugsweise stellt jedes Master-System dem ZDS die in einer zugehörenden Master-Sicht definierten Elemente seines Datenbestandes zur Verfügung, wobei in der Master-Sicht eines angeschlossenen Master-Systems die Elemente des Datenbestands enthalten sind, für die das System die Datenhoheit besitzt.
Gleichzeitig besitzt jedes Client-System über einen Datenzugriffsdienst Zugriff auf die in einer zugehörenden Client-Sicht definierten Daten, wobei in der Client-Sicht eines angeschlossenen Systems die Elemente des Datenbestands enthalten sind, für die das System Informationen vom ZDS abrufen kann.
In einer bevorzugten Ausbildung der Erfindung werden die Sichten für die angeschlossenen Systeme aus dem KOM durch die Operationen Projektion und Selektion gebildet.
Über die Projektion erfolgt eine Auswahl, welche Elemente im Form von Klassen, Attribute, Methoden, Beziehungen des KOM in einer Sicht enthalten sind. Durch eine Selektion erfolgt eine Auswahl einzelner Objekte einer Klasse. Eine Selektion ist hierbei nur in einer Client-Sicht möglich. Vorzugsweise ist für eine Klasse als Selektionskriterium eine Filterregel definiert, die bestimmt, welche Objekte in der Client-Sicht enthalten sind.
Erfindungsgemäß ist vorgesehen, dass die jeweilige Sicht auf den ZDS die Elemente des KOM bestimmt, die das angeschlossene System kennt, wobei eine Sicht beschrieben wird durch: - Klassen mit ihren
Attributen und
Methoden (inkl. Schnittstelle)
Selektionskriterien
- Beziehungen
- Konsistenzregeln.
Zur Kommunikation untereinander stehen den angeschlossenen Master- und Client- Systemen durch den ZDS mindestens zwei Kommunikationsmechanismen in Form eines Datenzugriffdienstes und eines Meldungsdienstes zur Verfügung, wobei alle vom ZDS bereitgestellten Dienste als Methoden im Objektmodell definiert sind. Bei den Diensten können Selektionskriterien angewandt werden, die zusätzlich einschränkend auf die bei den Klassen definierten Kriterien wirken.
Die Datenzugriffsdienste sind sowohl für Client- als auch Master-Systeme definiert. Die Client-Systeme definieren hierzu die für sie fachlich notwendigen Datenzugriffsdienste, mit denen sie auf die in der Client-Sicht definierten Daten zugreifen wollen.
Aus den Anforderungen der Client-Datenzugriffsdienste können dann Datenzugriffsdienste für die Master-Systeme definiert werden.
Die Meldungsdienste innerhalb des ZDS-Objektmodells sind sowohl in Master- als auch in Client-Sichten definiert. Über die Meldungsdienste werden Änderungen im Datenbestand eines Master-Systems an den ZDS gemeldet, wobei der ZDS diese Änderungen den betroffenen Client-Systemen zur Verfügung stellt.
Generell ist für jedes an den ZDS angeschlossene System eine eigene Klassenkategorie eingerichtet. Dabei kann jede Klassenkategorie selbst wieder zwei Klassenkategorien für Master- und Client-Sichten enthalten. Die spezielle Klassenkategorie KOM ist in mehrere nach bestimmten Kriterien gebildeten Unterkategorien untergliedert. Die Klassenkategorien enthalten:
- genau die Klassen (mit Attributen und Methoden) und deren Beziehungen, die in der jeweiligen Sicht sichtbar sind,
- mindestens ein Klassendiagramm, in dem die in der Sicht enthaltenen Klassen veranschaulicht werden,
- zu jeder Operation die Spezifikation der Signatur dieser Methode durch Angabe von Objektstrukturen.
Die Erfindung wird im folgenden anhand eines Ausführungsbeispiels unter Bezugnahme auf mehrere Zeichnungsfiguren näher beschrieben. Aus den Zeichnungen und ihrer Beschreibung ergeben sich weitere Merkmale, Vorteile und Anwendungen der Erfindung. Es zeigt:
Figur 1 : Übersicht eines ZDS-basierten Informationsverarbeitungssystems;
Figur 2: Darstellung der Hierarchie der Klassenkategorien im ZDS-
Objektmodell;
Figur 3: Definition der Schnittstelle einer Sicht;
Figur 4: Baumstruktur für Figur 3;
Figur 5: Struktur der Messagedaten;
Figur 6: Darstellung einer Update-Message mit alten und neuen Werten.
Wie in Figur 1 dargestellt, dient ein Zentraler DatenServer ZDS 1 als zentrale Kommunikationsinstanz zwischen technischen Anwendungen, die als Master- Systeme 3 und/oder Client-Systeme 2 auftreten können. Durch den Einsatz des ZDS 1 wird es möglich, die Kommunikation zwischen diesen Anwendungen mit einheitlichen Verfahren auf Basis einer vereinheitlichten Sicht (View) auf die Daten durchzuführen. Jedes Anwendungssystem 2; 3 benötigt nur noch eine Schnittstelle zum ZDS 1. Es ist nicht mehr notwendig, zwischen je zwei kommunizierenden Systemen eine eigene Schnittstelle zu entwickeln. Dadurch wird der Entwicklungsund Pflegeaufwand für die Schnittstellen wesentlich verringert. Der ZDS 1 selbst ist kein Anwendungssystem im eigentlichen Sinn. Er führt selbst keine fachlichen Funktionen aus, bietet keine direkte Benutzerschnittstelle und enthält selbst keine fachlichen Daten. Fachliche Funktionen, Benutzerschnittstellen und fachliche Datenhaltung finden in den einzelnen Anwendungssystemen 2; 3 statt. Der ZDS 1 greift lesend auf die Datenbestände der Anwendungssysteme zu und bietet Dienste an, durch die die Anwendungssysteme auf alle dem ZDS bekannten Datenbestände aller angeschlossenen Anwendungssysteme zugreifen können. Da viele der fachlichen Daten nur im jeweils spezifischen Anwendungssystem bearbeitet werden, wird in der Regel nur ein Teil des Datenbestandes über den ZDS 1 allgemein bekanntgemacht, und zwar der Teil, der auch von anderen Anwendungssystemen für ihre Aufgabenstellung benötigt wird. Die Summe aller über den ZDS 1 zugreifbaren Datenbestände wird in einem gemeinsamen Modell, dem Konzeptionellen Objektmodell (KOM) 4 des ZDS 1 beschrieben.
Die Dienste des ZDS 1 und der Zugang zu ihnen sind für alle angeschlossenen Systeme 2; 3 gleich. Für jedes System werden aber die jeweils spezifischen Dienste in einer besonderen Sicht auf das konzeptionelle Objektmodell 4 des ZDS 1 beschrieben. Diese spezifische Sicht (View) muss jeweils dem System und dem ZDS 1 bekannt sein und wird für jedes System einzeln festgelegt. Jedes angeschlossenere System kann gegenüber dem ZDS 1 in zwei verschiedenen Rollen auftreten: als Master-System 3 und/oder als Client-System 2.
Ein Master-System 3 stellt dem ZDS 1 den in einem jeweiligen Master-View 6 definierten Teil seines Datenbestandes zur Verfügung. Außerdem benachrichtigen die Master-Systeme 3 den ZDS 1 über Änderungen im eigenen Datenbestand. Ein Client-System 2 nutzt die vom ZDS 1 zur Verfügung gestellten Möglichkeiten zum Zugriff auf die in einem Client-View 5 definierten Daten. Meldungen über Datenänderungen in den in der Client-View 5 enthaltenen Datenbestand können vom Client-System 2 beim ZDS 1 abgeholt werden. Durch die Entkopplung von Master- 6 und Client-View 5 ist es möglich, dass bestimmte Änderungen an Master-Views 6 keine Auswirkungen auf die Client-Views
5 haben. Dies ist insbesondere der Fall, wenn die Zuständigkeit für einen
Datenbestand von einem Master-System 3 auf ein anderes übergeht.
Den angeschlossenen Master- 3 und Client-Systemen 2 stehen durch den ZDS 1 zwei Kommunikationsmechanismen zur Verfügung:
Datenzugriff und Meldungen.
Der Datenzugriffsdienst des ZDS 1 ermöglicht den Client-Systemen 2 den Zugriff auf die im ZDS 1 definierten Datenbestände. Der daraus resultierende Zugriff auf die für die gewünschten Daten zuständige Master-Systeme 3 ist für die Client-Systeme 2 nicht sichtbar, d.h. die Client-Systeme 2 haben keine Kenntnis, zu welchen Master- Systemen 3 die angeforderten Daten gehören.
Über den Meldungsdienst werden Änderungen im Datenbestand eines Master- Systems 3 an den ZDS 1 gemeldet. Der ZDS 1 stellt diese Änderungen dann den betroffenen Client-Systemen 2 zur Verfügung.
Die folgende Tabelle zeigt, welche Informationen für Datenzugriffs- und Meldungsdienst in den Master- und Client-Views enthalten sind:
Figure imgf000008_0001
Nachfolgend werden einige verwendete Begriffe aus dem Gebiet der Objektorientierung erläutert.
Assoziation
Eine Assoziation ist die allgemeinste Form einer Beziehung zwischen Klassen. Sie beschreibt Semantik und Struktur einer Menge von Objektbeziehungen.
Die Kardinalität der Assoziation bestimmt, wieviele Objekte der in Bezug stehenden
Klassen an einer Assoziation beteiligt sind.
Durch Angabe von Rollennamen wird die Semantik der Beziehung beschrieben, d.h. in welcher Rolle sehen Objekte der einen Klasse die Objekte der anderen Klasse.
Wenn eine Assoziation über eigene Attribute verfügt, dann handelt es sich um eine attributisierte Assoziation.
Attribut
Ein Attribut ist ein Datenelement, dass in jedem Objekt einer Klasse enthalten ist und in jedem Objekt einen individuellen Wert haben kann.
Ein Attribut wird beschrieben durch seinen Namen und seinen Typ.
Identifizierende Attribute zeichnen sich dadurch aus, dass sie ein Objekt eindeutig bestimmen, d.h. es gibt kein anderes Objekt mit den gleichen identifizierenden
Attributen.
Has-Beziehung
Die Has-Beziehung oder Aggregation ist eine besondere Form der allgemeineren Assoziationsbeziehung. Die beteiligten Klassen beschreiben eine Ganzes Teil- Hierarchie, d.h. eine Aggregation beschreibt, wie sich etwas Ganzes aus seinen Teilen zusammensetzt.
Klasse
Eine Klasse ist eine Menge von Objekten, die eine gemeinsame Struktur und ein gemeinsames Verhalten aufweisen. Die Struktur einer Klasse wird beschrieben durch die Attribute und Beziehungen zu anderen Klassen, das Verhalten durch die Operationen einer Klasse. Klassenkategorie
Klassenkategorien werden verwendet, um das logische Modell aufzuteilen. Eine
Klassenkategorie kann Klassen und andere Klassenkategorien enthalten. Sie enthält jedoch, im Gegensatz zu einer Klasse, direkt keine Operationen oder Zustände des
Modells.
Objektbeziehung
Eine Objektbeziehung (Link) ist eine konkrete Beziehung zwischen Objekten. Sie ist eine Instanz einer Assoziation.
Objekt
Ein Objekt ist eine konkret vorhandene Einheit, es hat einen Status, ein Verhalten und eine Identität. Jedes Objekt ist ein Exemplar (Instanz) einer Klasse. Die Information eines Objekts wird repräsentiert durch Attribute, deren Struktur in der Klasse definiert ist. Das Verhalten wird bestimmt durch die in der Klasse definierten Operationen und ist für alle Objekte einer Klasse gleich.
Vererbungsbeziehung
Die Vererbung ist eine Beziehung zwischen Klassen, wobei die eine Klasse (Sub- oder Unterklasse) die Struktur und das Verhalten der anderen Klasse (Super- oder Oberklasse) teilt. Die Unterklasse ist eine spezialisierte Art der Oberklasse.
Figur 2 zeigt den Aufbau des ZDS-Objektmodells 10 und die Regeln, nach denen die Sichten 5, 6 der angeschlossenen Systeme 2; 3 gebildet werden.
Das ZDS-Objektmodell 10 besteht aus dem Konzeptionellen Objektmodell (KOM) 4 und den Sichten 5, 6 (Views) der angeschlossenen Systeme. Daher wurde das Gesamtmodell in mehrere Kategorien aufgeteilt, wobei für jedes an den ZDS 1 angeschlossene System eine Kategorie 11 , 14 ,17 vorgesehen wird. Es gibt eine Kategorie ZDS-KOM 11 , die das KOM 4 enthält. Das KOM 4 selbst ist wiederum gegliedert in mehrere nach fachlichen Kriterien gebildeten Unterkategorien 12 ,13. Ferner bilden die angeschlossenen Systeme, z.B. System A und System B, jeweils eine Kategorie 14, 17, wobei der Name der Kategorie, die die Sicht des angeschlossenen Systems auf den ZDS 1 beinhaltet, z.B. das Postfix „View" zugeteilt bekommt (z.B. System A-View).
Jedes angeschlossene System kann gegenüber dem ZDS 1 als Master- 3 und/oder als Client-System 2 auftreten. Daher werden in den Kategorien 14 , 17 entsprechend der Rolle des Systems die Unterkategorien Master- View 15 bzw. 18 und Client-View
16 angelegt.
Daraus ergibt sich z.B. für das ZDS-Objektmodell 10 bei den angeschlossenen
Systemen "System A" 14 und "System B" 17 die in Figur 2 gezeigte Hierarchie von
Klassenkategorien.
Die Sicht 5, 6 (View) auf den ZDS 1 bestimmt die Elemente des KOM 4, die das angeschlossene System kennt. Sie wird beschrieben durch die darin enthaltenen
- Klassen mit ihren
Attributen und
Methoden (inkl. Schnittstelle)
Selektionskriterien
- Beziehungen
- Konsistenzregeln
In der Master-View 6 eines angeschlossenen Systems sind die Elemente enthalten, für die das System der "Master" ist, d.h. für die das System die Datenhoheit besitzt. Hierzu wird für jede Klasse ein primäres Master-System definiert. Dieses ist zuständig für die identifizierenden Attribute der Klasse, in vielen Fällen auch für alle anderen Attribute. Wenn jedoch für andere Attribute weitere Systeme verantwortlich sind, dann werden diese Systeme als sekundäres Master-System bezeichnet. In den Master-Views der sekundären Master-Systeme sind neben den "eigenen" Attributen zusätzlich die identifizierenden Attribute der Klasse enthalten.
In der Client-View 5 eines angeschlossenen Systems sind die Elemente enthalten, für die das System Informationen vom ZDS erhalten will.
Die Views 5, 6 für die angeschlossenen Systeme können nicht beliebig aus dem KOM 4 gebildet werden. Erlaubt sind die Operationen Projektion und Selektion. Andere Operationen als Selektion und Projektion sind nicht möglich! Es gibt z.B. keine Join-Operation, durch die mehrere Klassen des KOM 4 auf eine Klasse eines ZDS-Client-Views 5 abgebildet werden.
Über eine Projektion wird ausgewählt, welche Elemente (Klassen, Attribute, Methoden, Beziehungen) des KOM 4 in einer View 5, 6 enthalten sind. Alle anderen Elemente des KOM 4 werden durch die Projektion ausgeblendet.
Eine Selektion ist nur in einer Client-View 5 möglich. Durch eine Selektion können einzelne Objekte einer Klasse ausgewählt werden. Hierzu kann für eine Klasse als
Selektionskriterium eine Filterregel angegeben werden, die bestimmt, welche
Objekte in der Client-View 5 enthalten sind.
Die Filterregeln werden bei den Klassen des Client-Views 5 definiert. Sie werden z.B. in einer an die SQL-Sprache angelehnten Syntax angegeben.
Als Filterattribute werden die Attribute bezeichnet, die für die Auswertung von
Filterregeln notwendig sind.
Bezüglich Konsistenz im ZDS 1 gelten die folgenden Definitionen:
- Der ZDS 1 geht davon aus, dass zu jedem Zeitpunkt die Daten innerhalb eines Master-Systems 3 konsistent sind.
- Konsistenzbedingungen, die über Master-System-Grenzen hinausgehen, müssen fachlich spezifiziert sein. - Attribute, die zur Bewertung der Konsistenzbedingungen nötig sind, müssen im KOM 4 enthalten sein.
- Konsistenzbedingungen können in Client Views 5 definiert werden.
- Durch die Weitergabe von Daten durch den ZDS 1 darf sich die Konsistenz dieser Daten nicht vermindern.
Konsistenzregeln sind (im Gegensatz zu Filterregeln) auf der Basis eines Client- Views 5 definiert, d.h. dies entspricht der logischen Definition, dass ein Client-View 5 in sich konsistent sein muss.
Sind keine Konsistenzregeln auf den Client-Views 5 definiert, so wird davon ausgegangen, das die entsprechenden Daten immer konsistent zueinander sind. Als Konsistenzattribute werden die Attribute bezeichnet, die für die Auswertung von Konsistenzregeln notwendig sind. Die Syntax der Konsistenzregeln entspricht der Syntax der Filterregeln
Wie bereits weiter oben beschrieben, wird für jedes an den ZDS 1 angeschlossene System eine eigene Klassenkategorie modelliert, die selbst wieder zwei Klassenkategorien für Master- 6 und Client- View 5 enthalten kann.
Diese Kategorien enthalten:
- genau die Klassen (mit Attributen und Methoden) und deren Beziehungen, die in dem jeweiligen View sichtbar sind, wobei die Klassennamen nach den obigen Namenskonventionen gebildet sind,
- mindestens ein Klassendiagramm, in dem die in der View enthaltenen Klassen veranschaulicht werden,
- zu jeder Operation die Spezifikation der Signatur dieser Methode durch Angabe von Objektstrukturen spezifiziert wird.
Durch die Abbildung dieser Informationen ins ZDS-Objektmodell 10 wird es möglich, eine komplette Dokumentation des Objektmodells zu erstellen, die den funktionalen Teil des Fachkonzepts bildet. Außerdem ist es möglich, mit diesen Informationen Konfigurationsdateien zu erstellen, die in der ZDS-Anwendung zur Abbildung des KOM 4 auf die verschiedenen Views 5, 6 verwendet werden.
In den folgenden Abschnitten wird festgelegt, wie die beiden Regeln zur Bildung von Views 5, 6 (Projektion und Selektion) und die Spezifikation der Schnittstelle von Operationen im ZDS-Objektmodell 10 abgebildet werden.
Die Projektion für Klassen und Beziehungen erfolgt dadurch, dass in den Klassenkategorien der Views 5, 6 nur die Klassen und Beziehungen enthalten sind, die zu dem View gehören.
In diesen Klassen sind nur die Attribute und Operationen vorhanden, die zum View gehören. Hierbei gilt, dass die Attribute in den Klassen der View den gleichen Namen und Typ haben, wie die Attribute der entsprechenden Klasse des KOM 4. Bei den Operationen gilt analog Gleichheit von Namen und Schnittstelle.
Zu den in der View enthaltenen Elementen können View-spezifische Beschreibungen in dem "Documentation"-Feld des jeweiligen Spezifikationsdialogs angegeben werden.
Die Selektion, d.h. eine zusätzliche Filterung, lässt sich in der Booch-Notation nicht ausdrücken. Im Rose-Modell werden daher die Selektionskriterien in dem Property 'Selektionskriterium' der zum View gehörenden Klasse angegeben.
Konsistenzregeln werden auf Basis einer Client-View 5 definiert. Daher werden die Konsistenzregeln im Rose-Modell in dem Property 'Konsistenzregel' der Client- View- Kategorie abgebildet.
Vom ZDS 1 werden verschiedene Arten von Diensten (Services) bereitgestellt:
- Retrieve-Services zur Nutzung des Datenzugriffsdienstes
- Message-Services zur Nutzung des Meldungsdienstes Alle Services werden grundsätzlich als Methoden im Objektmodell 10 abgebildet. Für diese Methoden werden keine Aufrufparameter definiert, diese sind durch die vorhandenen C-API-Funktionen definiert.
Bei Services können ebenfalls Selektionskriterien angegeben werden. Sie wirken zusätzlich einschränkend auf die bei den Klassen definierten Kriterien. Definiert werden sie in dem Property 'Selektionskriterium' der betreffenden Methode. Um den geltenden Regeln zur Bildung von Client- und Master-Views 5, 6 gerecht zu werden, müssen die Methoden auch im KOM 4 an den entsprechenden Klassen modelliert werden.
Für beide Arten von Services werden an der Schnittstelle komplexe Baumstrukturen übergeben. Deren Aufbau muss zur Erstellung des Fachkonzepts für jeden Service spezifisch definiert werden. Diese Datenstrukturen müssen auf die jeweilige View abbildbar sein, d.h.
- Es dürfen nur bekannte Klassen, Attribute und Relationen benutzt werden.
- Referenzen auf Unterobjekte können gebildet werden aus Has-Beziehungen und Assoziationen, wobei der Name der Referenz dem Namen der Has-Beziehung bzw. dem Rollennamen der Assoziation entspricht.
- Die Kardinalität einer Beziehung bestimmt, ob es sich um ein einzelnes Objekt (Kardinalität <= 1 ) oder um eine Liste von Objekten handelt (Kardinalität > 1 ) Hier gibt es jedoch eine Ausnahme:
Wenn sicher ist, dass durch die Auswertung von Selektionskriterien bei einer Beziehung mit Kardinalität > 1 genau ein Objekt geliefert wird, dann kann dies in der Datenstruktur durch Angabe eines einzelnen Objektes dargestellt werden.
- In der View vorhandene attributisierte Assoziationen werden aufgelöst, wie dies in Figur 3 unter Verwendung der Booch-Notation dargestellt ist.
Die zugehörige Baumstruktur zeigt Figur 4. Von Klasse A 19 aus kann über den Klassennamen der Link-Klasse 21 zu dieser navigiert werden, wobei die Kardinalität der Beziehung auf der seitens der Klasse B bestimmt, ob von der Link-Klasse ein oder mehrere Objekte vorhanden sind. Von der Link-Klasse aus kann dann über den Rollennamen (Identifizierendes Attribut B) zur Klasse B 20 navigiert werden (Figur 3)
Datenzugriffsdienste (Retrieve-Services) werden für Client- 2 und Master-Systeme 3 definiert. Client-Systeme 2 definieren die für sie fachlich notwendigen Retrieve- Services, mit denen sie auf die in der Client-View 5 definierten Daten zugreifen wollen.
Aus den Anforderungen der Client-Retrieve-Services werden Retrieve-Services für die Master-Syteme 3 definiert. Diese nutzt der Datenzugriffsdienst zur Ermittlung der Daten, die von den Client-Systemen 2 angefordert werden. Im Objektmodell werden Retrieve-Services als Klassenmethoden der jeweiligen Klasse modelliert.
Nachrichtendienste (Message-Services) werden innerhalb des ZDS-Objektmodells 10 sowohl in Master- 6 als auch in Client-Views 5 definiert. In einem Master-View 6 werden die Messages definiert, die das Master-System 3 an den ZDS 1 sendet. In einem Client-View 5 werden die Messages definiert, die vom ZDS 1 an das Client- System 2 gesendet werden. Eine Message wird als Methode der jeweiligen Klasse definiert.
Client-Systeme erhalten nur Messages, die für sie interessant sind, d.h. die den Datenbestand des jeweiligen Clients betreffen. Hierzu müssen bei der Verarbeitung die Selektionskriterien beachtet werden.
Zu einer Message gehören folgende Angaben:
- eine eindeutige Message-Id,
- die Angabe, für welche Client-View 5 die Message bestimmt ist (Argument 'userview'),
- einen Messagetyp (Argument 'message'), - den Zeitpunkt, an dem die in der Message enthaltenen Daten gültig sind,
- die Angabe, von welchem Master-System 3 die Message gesendet wurden und
- die Messagedaten (in Form einer ZDS_OEDATA-Datenstruktur)
- Messagetypen
Es existieren folgende Arten von Messagetypen:
- New. vergleichbar mit einer Konstruktor-Methode einer Klasse
- Update: vergleichbar mit einer 'normalen' Methode einer Klasse
- Delete: vergleichbar mit einer Destruktor-Methode einer Klasse
Figur 5 stellt die Grundstruktur der Messagedaten da. Bei der Verarbeitung einer Message in der CM-Komponente müssen dort die Mesagedaten gelesen werden. In der Datenstruktur (Funktionsparameter 'message_data') sind maximal zwei Einträge enthalten:
- Ein boolescher Wert 'filter' und
- eine ZDS DEDATA-Datenstruktur 'data'
Der Wert 'filter' ist in jeder Update-Message vorhanden, die an ein Client-System 2 gesendet wird, und enthält den Wert, der bei der Auswertung der Filterregel ermittelt wurde. Wenn beim Client 2 keine Filterregel definiert wurde, ist der Wert TRUE eingetragen. Das Ergebnis der Filterregel ist für die Behandlung von Update- Messages auf Client-Seite erforderlich.
Die Unterstruktur 'data' ist in jeder Message enthalten, sowohl in den Messages ür die Client-Systeme 2 als auch in den Messages, die von den Master-Systemen 3 an den ZDS 1 gesendet werden. Der Aufbau der Unterstruktur ist abhängig von der jeweiligen Spezifikation der Message.
In einem Client-System 2 entspricht der Aufbau von 'data' genau den Elementen, die das Client-System 2 erhalten möchte. Aus den Anforderungen verschiedener Client- Systeme 2 für einen bestimmten Messagetyp einer Klasse ergibt sich der Aufbau der entsprechenden Message im Master-System 3: Deren 'data'-Struktur muss so definiert sein, dass darin alle Informationen dieses Masters enthalten sind, die zu dieser Message gehören.
Der Inhalt der Unterstruktur 'data' ist abhängig vom Messagetyp:
- Messagetyp New. 'data' enthält die Daten des neuen Objekts.
- Messagetyp Update: 'data' enthält die neuen Daten des Objekts.
- Messagetyp Delete: 'data' enthält die Daten des zu löschenden Objekts.
Bei der Spezifikation einer Update-Message in einer Master-View 6 kann zusätzlich angegeben werden, ob auch die alten Werte geliefert werden. Diese Angabe wird in der Master-View 6 in dem ZDS-Property 'Messagedaten Master' der jeweiligen Methode angegeben.
Bei der Spezifikation einer Update-Message in einer Client-View 5 kann zusätzlich angegeben werden,
- ob das Client-System 2 auch die alten Werte erhalten möchte und
- ob das Client-System 2 an allen Werte oder nur an den geänderten Werte interessiert ist.
Diese Angabe wird in der Client-View 5 in dem ZDS-Property 'Messagedaten Client' der jeweiligen Methode angegeben.
Wie in Figur 6 dargestellt ist, werden in Update-Messages, falls vorhanden, alte Werte folgendermaßen dargestellt: Statt des eigentlichen Attributwerts befindet sich in der Datenstruktur ein Objekt der Klasse 'changed'. Dieses Objekt hat die Attribute 'new' und 'old', die den neuen bzw. alten Attributwert beinhalten.
Die Klasse 'changed' wird eigens für diesen Zweck definiert. Sie wird zwar bei der Definition der Messagedaten-Struktur nicht verwendet, ist jedoch, falls die alten Werte geliefert werden, in der Datenstruktur enthalten. Das Beispiel gemäss Figur 6 zeigt die Datenstruktur für den Fall, dass das Attribut A der Klasse C geändert wurde:
Zeichnungslegende
Zentraler Datenserver (ZDS)
Client-System
Master-System
Konzeptionelles Objektmodell (KOM)
Client-Sicht (View)
Master-Sicht (View)
Datenzugriff
Meldungsdienst
ZDS-Objektmodell
Kategorie (ZDS.-KOM)
Unterkategorie
Unterkategorie
Kategorie (View)
Unterkategorie (Master-View)
Unterkategorie (Cient-View)
Kategorie (View)
Unterkategorie (Master-View)
Klasse
Klasse
Link-Klasse

Claims

Patentansprüche
1. Informationsverarbeitungssystem welches umfasst: eine zentrale Kommunikationsinstanz ZDS (1) zur Verwaltung und Weiterleitung von Informationen eines Datenbestandes, mindestens ein Master-Informationsverarbeitungssystem (3), welches über eine
Schnittstelle mit dem ZDS (1) kommuniziert, und dem ZDS (1) auf Anforderung
Informationen zur Verfügung stellt, mindestens ein Client-Informationsverarbeitungssystem (2), welches über eine
Schnittstelle mit dem ZDS (1) kommuniziert und auf Anforderung Informationen vom ZDS (1) erhält, wobei die vom ZDS (1) verwalteten Informationen durch ein Objektmodell (10) beschrieben sind, das ein konzeptionelles Objektmodell KOM (4) umfasst, das den gesamten von den Master- und Client-Systemen (2; 3) bereitgestellten
Datenbestand beschreibt, und den angeschlossenen Systemen zugeordnete und die jeweils spezifischen Dienste in bezug auf das KOM (4) beschreibende
Sichten (5; 6) (Views), welche die Elemente des vom ZDS (1) verwaltenden
Datenbestands bestimmen, die die betreffenden Systeme (2; 3) kennen.
2. Informationsverarbeitungssystem nach Anspruch 1 , dadurch gekennzeichnet, dass jedes Master-System (3) dem ZDS (1) die in einer zugehörenden Master- Sicht (6) definierten Elemente seines Datenbestandes zur Verfügung stellt.
3. Informationsverarbeitungssystem nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass in der Master-Sicht (6) eines angeschlossenen Master- Systems (3) die Elemente des Datenbestands enthalten sind, für die das System die Datenhoheit besitzt.
4. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jedes Client-System (2) über einen Datenzugriffsdienst Zugriff auf die in einer zugehörenden Client- Sicht (5) definierten Daten besitzt.
5. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der Client-Sicht (5) eines angeschlossenen Systems (2) die Elemente des Datenbestands enthalten sind, für die das System Informationen vom ZDS (1) abrufen kann.
6. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Sichten (5; 6) für die angeschlossenen Systeme aus dem KOM (4) durch die Operationen Projektion und Selektion gebildet werden.
7. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass über die Projektion eine Auswahl erfolgt, welche Elemente im Form von Klassen, Attribute, Methoden, Beziehungen des KOM (4) in einer Sicht (5; 6) enthalten sind.
8. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass durch eine Selektion eine Auswahl einzelner Objekte einer Klasse erfolgt.
9. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Selektion nur in einer Client-Sicht (5) möglich ist.
10. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für eine Klasse als Selektionskriterium eine Filterregel definiert wird, die bestimmt, welche Objekte in der Client-Sicht (5) enthalten sind.
11. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die jeweilige Sicht (5; 6) auf den ZDS (1) die Elemente des KOM (4) bestimmt, die das angeschlossene System (2; 3) kennt, wobei eine Sicht (5; 6) beschrieben wird durch:
- Klassen mit ihren
Attributen und
Methoden (inkl. Schnittstelle)
Selektionskriterien
- Beziehungen
- Konsistenzregeln.
12. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass den angeschlossenen Master- und Client-Systemen (2; 3) durch den ZDS (1) mindestens zwei Kommunikationsmechanismen in Form eines Datenzugriffdienstes und eines Meldungsdienstes zur Verfügung gestellt werden.
13. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass alle vom ZDS (1) bereitgestellten Dienste als Methoden im Objektmodell definiert sind.
14. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei den Diensten Selektionskriterien angewandt werden, die zusätzlich einschränkend auf die bei den Klassen definierten Kriterien wirken.
15. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Datenzugriffsdienste für Client- und Master-Systeme (2; 3) definiert sind.
16. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Client-Systeme (2) die für sie fachlich notwendigen Datenzugriffsdienste definieren, mit denen sie auf die in der Client-Sicht (5) definierten Daten zugreifen wollen.
17. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass aus den Anforderungen der Client-Datenzugriffsdienste Datenzugriffsdienste für die Master-Systeme (3) definiert werden.
18. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass über den Meldungsdienst Änderungen im Datenbestand eines Master-Systems (3) an den ZDS (1) gemeldet werden und der ZDS (1) diese Änderungen den betroffenen Client-Systemen (2) zur Verfügung stellt.
19. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Meldungsdienste innerhalb des ZDS-Objektmodells (10) sowohl in Master- als auch in Client-Sichten (5; 6) definiert sind.
20. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für jedes an den ZDS (1) angeschlossene System (2; 3) eine eigene Klassenkategorie eingerichtet ist.
21. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jede Klassenkategorie selbst wieder zwei Klassenkategorien für Master- und Client- Sichten (5; 6) enthalten kann.
22. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Klassenkategorie KOM (11) in mehrere nach bestimmten Kriterien gebildeten Unterkategorien (12; 13) untergliedert ist.
23. Informationsverarbeitungssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Klassenkategorien enthalten:
- genau die Klassen (mit Attributen und Methoden) und deren Beziehungen, die in der jeweiligen Sicht (5; 6) sichtbar sind,
- mindestens ein Klassendiagramm, in dem die in der Sicht (5; 6) enthaltenen Klassen veranschaulicht werden,
- zu jeder Operation die Spezifikation der Signatur dieser Methode durch Angabe von Objektstrukturen.
24. Verfahren zum Betrieb eines Informationsverarbeitungssystems, gekennzeichnet durch:
Bereitstellung einer zentralen Kommunikationsinstanz ZDS (1) zur Verwaltung und Weiterleitung von Informationen eines Datenbestandes,
Bereitstellung mindestens eines Master-Informationsverarbeitungssystems (3), welches über eine Schnittstelle mit dem ZDS (1) kommuniziert, und dem ZDS (1) auf Anforderung Informationen zur Verfügung stellt,
Bereitstellung mindestens eines Client-Informationsverarbeitungssystems (2), welches über eine Schnittstelle mit dem ZDS (1) kommuniziert und auf
Anforderung Informationen vom ZDS (1 )erhält, wobei die vom ZDS (1) verwalteten Informationen in ein Objektmodell (10) gegliedert sind, das ein konzeptionelles Objektmodell KOM (4) umfasst, das den gesamten von den Master- und Client-Systemen (2; 3) bereitgestellten Datenbestand beschreibt, und den angeschlossenen Systemen zugeordnete und die jeweils spezifischen Dienste in bezug auf das KOM (4) beschreibende Sichten (5; 6) (Views), welche die Elemente des vom ZDS (1) verwaltenden Datenbestands bestimmen, die die betreffenden Systeme (2; 3) kennen.
PCT/DE2001/001932 2000-05-23 2001-05-23 Informationsverarbeitungssystem und verfahren zu dessen betrieb WO2001090827A2 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
AU2001265806A AU2001265806A1 (en) 2000-05-23 2001-05-23 Information processing system and method for operation thereof
EP01943124A EP1285315B1 (de) 2000-05-23 2001-05-23 Informationsverarbeitungssystem und verfahren zu dessen betrieb
US10/276,987 US20040093606A1 (en) 2000-05-23 2001-05-23 Information processing system and method for operation thereof
PL01365905A PL365905A1 (en) 2000-05-23 2001-05-23 Information processing system and method for operation thereof

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10025050.5 2000-05-23
DE10025050A DE10025050A1 (de) 2000-05-23 2000-05-23 Informationsverarbeitungssystem und Verfahren zu dessen Betrieb

Publications (2)

Publication Number Publication Date
WO2001090827A2 true WO2001090827A2 (de) 2001-11-29
WO2001090827A3 WO2001090827A3 (de) 2002-11-21

Family

ID=7642954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2001/001932 WO2001090827A2 (de) 2000-05-23 2001-05-23 Informationsverarbeitungssystem und verfahren zu dessen betrieb

Country Status (8)

Country Link
US (1) US20040093606A1 (de)
EP (1) EP1285315B1 (de)
AU (1) AU2001265806A1 (de)
CZ (1) CZ306010B6 (de)
DE (1) DE10025050A1 (de)
PL (1) PL365905A1 (de)
RU (1) RU2276403C2 (de)
WO (1) WO2001090827A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10219913A1 (de) * 2002-05-03 2003-11-20 Siemens Ag Automatisierungswerkzeug
DE10219911A1 (de) * 2002-05-03 2003-11-20 Siemens Ag Automatisierungswerkzeug
US8010375B2 (en) * 2004-05-11 2011-08-30 Sap Ag Object model for global trade applications
CN102331930B (zh) * 2011-07-13 2014-12-10 北京邮电大学 一种信息系统灾难恢复时间目标的计算方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2319863A (en) 1996-11-30 1998-06-03 Int Computers Ltd Groupware adapted for inter/intranet

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5329619A (en) * 1992-10-30 1994-07-12 Software Ag Cooperative processing interface and communication broker for heterogeneous computing environments
US5797136A (en) * 1995-10-05 1998-08-18 International Business Machines Corporation Optional quantifiers in relational and object-oriented views of database systems
US6246410B1 (en) * 1996-01-19 2001-06-12 International Business Machines Corp. Method and system for database access
GB2310574B (en) * 1996-02-22 2000-05-31 Dsc Telecom Lp Handling of commands passed between server and client stations of a telecommunications system
US5760770A (en) * 1996-05-15 1998-06-02 Microsoft Corporation System and method for defining a view to display data
US5958012A (en) * 1996-07-18 1999-09-28 Computer Associates International, Inc. Network management system using virtual reality techniques to display and simulate navigation to network components
US5917498A (en) * 1996-11-12 1999-06-29 International Business Machines Corporation Multi-object views in an object modeling tool
US5983267A (en) * 1997-09-23 1999-11-09 Information Architects Corporation System for indexing and displaying requested data having heterogeneous content and representation
US6700590B1 (en) * 1999-11-01 2004-03-02 Indx Software Corporation System and method for retrieving and presenting data using class-based component and view model

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2319863A (en) 1996-11-30 1998-06-03 Int Computers Ltd Groupware adapted for inter/intranet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SOON-YOUNG HUH: "An object-oriented database model for a change management framework in workgroup computing systems", INFORMATION AND SOFTWARE TECHNOLOGY, vol. 40, no. 2, 25 May 1998 (1998-05-25), pages 79 - 92

Also Published As

Publication number Publication date
DE10025050A1 (de) 2001-12-06
PL365905A1 (en) 2005-01-10
EP1285315A2 (de) 2003-02-26
US20040093606A1 (en) 2004-05-13
RU2276403C2 (ru) 2006-05-10
CZ20024204A3 (cs) 2003-05-14
CZ306010B6 (cs) 2016-06-22
WO2001090827A3 (de) 2002-11-21
EP1285315B1 (de) 2012-05-23
AU2001265806A1 (en) 2001-12-03

Similar Documents

Publication Publication Date Title
DE69315378T2 (de) Einen dynamischen Nachrichtenservice verwendendes objektorientiertes Softwaresystem, besonders für eine Kontroll-/Steuer-Vorrichtung für eine redundante Architektur
DE69934894T2 (de) Verfahren und vorrichtung zur wahlweisen einstellung des zugangs zu anwendungsmerkmalen
EP1258812B1 (de) Virtuelle Datenbank heterogener Datenstrukturen
DE69408337T2 (de) Steuersystem einer relationellen datenbank gemäss einer objekt-orientierten logik, die die zugriffe auf die datenbank verringert, und entsprechendes verfahren
DE10031716B4 (de) Abonnement und Benachrichtigung bei Datenbanktechnik
DE68926345T2 (de) Datenverarbeitungsnetzwerk
DE69800428T2 (de) Informationsverarbeitungssystemarchitektur
DE10003015A1 (de) Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen
EP1151399A1 (de) Integration heterogener Datenbank-Systeme
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE68924977T2 (de) Steuermodul für eine Arbeitsstation.
DE102012001406A1 (de) Automatische Konfiguration eines Produktdatenmanagementsystems
DE69803468T2 (de) Vorrichtung und verfahren zur erzeugung eingekapselter und leistungseffizienter datenreferenzen in einer objektorientierten steuerung und verteiltes steuersystem
EP1821165B1 (de) Nutzung von Variablen in mehreren Automatisierungssystemen
WO2001090827A2 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
EP3441919A1 (de) Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens
EP1516234A2 (de) Informationserzeugungssystem für die produktentstehung
DE69522855T2 (de) Informationssystem zur Abfrage von aus betrieblichen Applikationen stammenden zentralisierten Informationen
EP1099172B1 (de) Verfahren, anordnung und satz mehrerer anordnungen zur behebung mindestens einer inkonsistenz in einer datenbankmenge, die eine datenbank sowie mindestens eine kopiedatenbank der datenbank aufweist
DE112007000461T5 (de) Kontrolle eines Objekts der realen Welt in verbundenen Systemen
EP1054528B1 (de) Verfahren zum Ausführen einer Anforderung einer Netzwerkverwaltungseinrichtung
DE102006037968B4 (de) Universelle und erweiterbare Datenverwaltung mit Beobachtungs- und Interprozesskommunikations-Mechanismen
EP1332446A2 (de) System, verfahren und computerprogramm zur konfiguration von objekten
DE69620303T2 (de) Verfahren und Gerät zum Teilen von Verwaltungsinformationen über einen gemeinsamen Speicher
DE60000301T2 (de) Verfahren, gerät, und hergestellter gegenstand für beinamen

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2001943124

Country of ref document: EP

AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: PV2002-4204

Country of ref document: CZ

WWP Wipo information: published in national office

Ref document number: 2001943124

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10276987

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: PV2002-4204

Country of ref document: CZ

NENP Non-entry into the national phase

Ref country code: JP