5. Datenbasis (Repositorium) und Austauschformatest.inf.tu-dresden.de/Lehre/WS09-10/sew/slides/sew-05-repository.pdf · DFD DFD Printer Parser M3 MOF ERD-T M2 M1 TS MOF TS CDIF. Prof

SEW, © Prof. Uwe Aßmann 1

5. Datenbasis (Repositorium) und Austauschformate

Prof. Dr. Uwe Aßmann

Technische Universität Dresden

Institut für Software- und Multimediatechnik

http://st.inf.tu-dresden.de

Version 09-0.4, 02.12.09

1) Ziele

2) Architektur

3) Beispiele

4) Austauschformate

5) Frameworks zur Werkzeug- integration (PCTE)

Prof. U. Aßmann, SEW 2

Literatur

► Netbeans Metadata repository (MDR) http://docs.huihoo.com/netbeans/netbeanstp.pdf


5.1 Ziele und Aufgabender Datenbasis (Repositoriums)


Aufgaben des Repository

Eine Datenbasis (Repositorium, repository) ist die Ablage aller Informationen eines Systems, ohne genauer Art und Umfang der Ablage festzuschreiben. In einer SEU enthält es alle passiven und aktiven Komponenten zur Handhabung der Basisinformationen der Werkzeuge [12, S. 121ff.].

Repository

Komponenten-bank

CASE-Tools

Fenster-system

Ausgabe-system

WeitereWerk-zeuge

Retrieval-System

Programmier-system


Zielstellungen für Repositories

► Transparente persistente Dokumentspeicherung: Einfache Abbildung aller Datenobjekte eines SE-Modells (Dokument, graph. Parameter) auf persistente Datenstruk-turen im Repository auch bei Änderung der Objekte (Systemausfall)

► Entkopplung: Physische und logische Datenunabhängigkeit, d.h. Trennung der Programme (Werkzeuge) von physischer bzw. konzeptioneller Repräsentation der Daten

► Abhängigkeit von Schemata:■ Datenmodell: Transparent und über mehrere Metamodellebenen für die

auszutauschenden Daten zwischen Repository und Werkzeugen leicht handhabbar

■ Externe Schemata: Für Steuerung des Zugriffs, in dem zu unterschiedlichen Rollen verschiedene externe Schemata für ein Dokument defi nierbar sind

■ Schema-Änderungen: Sollen bestehende Daten in der Datenbasis erhalten■ Schnittstellen: Programmierbare APIs (Anfragesprachen, prozedurale Pro-

grammierschnittstellen), möglichst aus Metadaten generiert ► Administration: Verfügbarkeit allgemeiner Verwaltungsfunktionen und auch für die

Erstellung administrativer Ausgaben (Statistiken)

Quelle: nach Habermann, H.-J., Leymann, F.: Repository - eine Einführung; Oldenbourg Verlag 1993 und Däberitz, D.: Der Bau von SEU mit NDBMS; Diss. Uni Siegen 1997


Zielstellungen für Repositories (2)

► Effektive Arbeitsweise:■ Verteilung: Zugriff von verschiedenen Orten aus und Bereitstellung einheitli-

cher Basisfunktionen für die kooperierende Arbeit mehrerer Benutzer(-gruppen)■ Transaktionen: Dienen der Synchronisation von Metadaten und Objektdaten.

Sie können dazu benutzt werden, um temporär inkonsistente Zwischenzustände von Dokumenten zu verwalten

■ Leistungsfähigkeit: Notwendig insbesondere für schnellen, effi zienten Zugriff auf umfangreiche Dokumente

■ Versionen: Verwaltung unterschiedlicher, zu einem Projekt gehörender Ent-wicklungsstände von Dokumenten

■ Usability: Einfache Bedienung durch einheitliche ergonomische Benutzungs-oberfl ächen

► Entwicklungsqualitäten:■ Adaptierbarkeit: Einbettung des Repository in gewünschte

Entwicklungsrichtung (kommerzielle oder technische Informationssysteme, Standardsoftware)

■ Portabilität: Zukunftssicherheit - Standardkonformität – Aufwärtskompatibilität

Quelle: nach Habermann, H.-J., Leymann, F.: Repository - eine Einführung; Oldenbourg Verlag 1993 und Däberitz, D.: Der Bau von SEU mit NDBMS; Diss. Uni Siegen 1997


Kollaboration von Werkzeugen auf dem Repositorium mit Rollenobjekten

Werkzeug Werkzeug

Material

Leseschicht

Schreibschicht

Verteilungsschicht

Authentifikationsschicht

Werkzeug

Verteilungs-rolle

Authentifikations-rolle

Lese-rolle

Schreib-rolle

Material-Kern

Material-Rolle

Kollaborations-schichten

Speicher aller komplexen Objekte

Werkzeug-Schicht


5.2 Architektur von Repositories


Repository - Datenintegrationsstufen

Integrationsart Schema Wirkungsweise

Black-box-Integration(schwach)

Grey-box-Integration

(mittel)

White-box-Integration

(stark)

CASEtool

Repo-sitoryDateien

check out

CASEtool

CASEtool

Daten Daten

check in

CASEtool

CASEtool

Daten-schema

Daten

...

• Werkzeug arbeitet isoliert wie bisher auf eigenen Datenstrukturen• Repositorium stellt Daten bereit (check out)• Nach Werkzeugarbeit Ablage in Repositorium (check in)• Repositorium stellt Dienste zur Verfügung

• Werkzeugzugriffe durch Repository-Dienste ersetzt• Unterstützung von Datenintegrität und Interoperabi- lität zwischen Werkzeugen• Keine Offenlegung essentieller Bestandteile der Werkzeug-Implementierung• Verkapselung in einem Zugriffsmodul

• Definition einheitl. Datenschema für alle Werkzeuge• Alle Werkzeuge setzen über Zugriffsdienste darauf auf• Einfache Sicherung von Konsistenz, Datenintegrität und Datensicherheit• Werkzeuge sind ständig (bei Änderung) an Daten- schema anzupassen

Quelle: [Bal-II, S. 608]

...

Repository

Repository


Grobarchitektur bei Datenteilung (Metamodellgesteuertes Repositorium

Tools

Repositorium

Daten-basis desProjektes

Metadaten-verwaltungssystem

INTERFACETool-Export-Import

Schnittstelle

persistente Objekt-

speicherung

Operationen zurDatenverwaltungund -manipulation


DFD

OO

A

ERD

Metametamodell-Schicht

Metamodell-Schicht

Modell-Schicht

Daten-Schicht

Archive

d

Contro

lled

Uncontrolled

M3

M0

M1

M2

Definiert

Kontrolliert

Definiert

Kontrolliert

Definiert

DictionaryDefinitionSchemaSchicht

DictionaryDefinitionSchicht

DictionarySchicht

Anwendungs-Schicht

(Daten der "Realen Welt")

(Fixiert durch Standard)

IRDS/MOF Metahierarchie (Wdh.)

NotesDatenbanken

realeDatenbasis


5.3 Beispiele


Beispiele für Repositories

Quelle: Habermann, H.-J., Leymann, F.: Repository - eine Einführung; Oldenbourg Verlag 1993

Bezeichnung Kurzcharakteristik

IBM Repository Manager Repository für AD/Cycle, offene Architektur für leichten Anschluss von Tools, teamorientiert

WebSphere Repository Database von IBM

Administration-Tools zur Installation, Überwachung und Pfl ege von Datenquellen und Enterprise Applications

SAP R/3-System Eigentlich R/3-Data-Dictionary für Ablage von Metadaten auf Basis tabellarischer Datenstrukturen. DD-Tabellen ursächlich für Speicherung kommerzieller Daten aber auch für R/3-Entwicklungsumgebung

SAP NetWeaver Master Data Management (MDM)

Verteilte Stammdatenverwaltung zur Pfl ege, Konsolidierung und Harmonisierung integrierter Informationen über gültige Stammdatenattribute

PCTE Object Management System

innerhalb einer PCTE-Umgebung


Beispiele

Bezeichnung Kurzcharakteristik

Hibernate Object-relational mapper (ORM); Abbildung von Java-Objekten auf Relationen, analog zu ERD-Abbildung, Verwendung von verschiedenen SQL-Datenbanken

Netbeans Metadata Repository (MDR)

Metasprache MOF; Laden von Metamodellen möglich; Generierung von Modell-Zugriffsschnittstellen; reflektiver Zugriff auf Modelle

Eclipse EMF Metasprache EMOF; ansonsten wie oben

Subversion/CVS/git Versionsverwaltungssysteme auf File-Basis; Verwaltung von Versionen aller Files und Verzeichnisse


AD/CYCLE-Architektur (IBM)

User Interface

Workstation Service

Work Management

Tool Services

AD Information Model

LibraryService

RepositoryService

ADPlatform

ADTools

Quelle: [1, S. 141]


SAP NetWeaver MDM

Master Data Management (MDM)

Repository

MDM Server

MDMImport Manager

SAP NetWeaver XI

MDM Data Manager

Legacysystem

SAP R/3system

Non-SAPsystem

Converts data intoXML format

• Import new objects• Match and merge

identical or duplicate objects centrally

• Provide relevant key mapping information

• Search and identify identical master data objects

• Merge identical objects centrally

• Provide relevant key mapping information

Quelle: URL: http://SDN.SAP.COM,Artikel von David, Klaus

http://sdn.sap.com/


Metamodellgesteuerte Repositorien

► Ein metamodellgesteuertes Repositorium erlaubt es, verschiedene Metamodelle zu laden, auch gleichzeitig

■ Ist zugeschnitten auf eine Metasprache■ Speicherung von Metadaten möglich (metadata repository), aber auch

Modellen (model repository)

► Vorteile:■ Generierung von Zugrifsschnittstellen zu den Modellen (starke

Typisierung)■ Verwendung von refektiven Zugrifsschnittstellen zu den Modellen

(schwache Typisierung). z.B. Zugrif auf Extent: Zugrif auf alle Modelle eines Metamodells oder alle

Objekte eines Modells

■ Observation der Modelle möglich (durch Einhängen von Observern)


Netbeans MDR

► Ein metamodellgesteuertes Repositorium für die Netbeans SEU http://www.netbeans.org, Metasprache MOF

■ Speicherung von MOF-Metamodellen und -Metadaten möglich (metadata repository), aber auch Modellen (model repository)

► Vorteile:■ Generierung von Java-Zugrifsschnittstellen zu den Modellen (starke

Typisierung), via JMI (MOF-Java-Mapping)■ Verwendung von refektiven Zugrifsschnittstellen zu den Modellen

(schwache Typisierung). Via Refektion auf MOF-Konzepten (Klassen, Attributen, Assoziationen,

Vererbung). Zugrif auf Extent

■ Observation der Modelle möglich ■ Transparente Speicherung im Hauptspeicher, Filesystem oder in einer

Datenbank■ Austauschformat XMI (MOF-XML-Mapping)

http://www.netbeans.org/


Netbeans MDR

MOF-Metamodell

M3

M2

M1

MOF

MOF UML CWM

MOF-JavaAccessPackage

UML-JavaAccessPackage

CWM-JavaAccessPackage

M0MOF-JavaObjects

UML-JavaObjects

CWM-JavaObjects

laden

MOF-JavaDatabaseObjects

UML-JavaXMLObjects

CWM-JavaFileObjects

Persistenz auf Datei,Datenbank, etc. in verschiedenen Repräsentationen

<<generates>>


Eclipse EMF (basierend auf EMOF)

EMOF-Metamodell

M3

M2

M1

EMOF

EMOF UML CWM

EMOF-JavaAccessPackage

UML-JavaAccessPackage

CWM-JavaAccessPackage

M0EMOF-JavaObjects

UML-JavaObjects

CWM-JavaObjects

laden

EMOF-JavaDatabaseObjects

UML-JavahibernatedObjects

CWM-JavaFileObjects

Persistenz auf Datei,Datenbank, etc. in verschiedenen Repräsentationen

<<generates>>


5.4 Austauschformate

Einsatz in Transformations-Brücken zwischen Repositorien


Austauschformat konkrete Syntax

► Als Austauschformat ist von jeher konkrete textuelle Syntax benutzt worden (mittels Technologieraum Grammarware, mit Metasprache EBNF)

■ Parser lesen den Text und wandeln ihn in das interne Format■ Prettyprinter schreiben das interne Format um auf die konkrete Syntax


Transformative TS-Brücken mit konkreter Syntax

► Eine Technologieraum-Brücke (TS-Brücke, TS bridge) bietet■ ein Austauschformat in konkreter Syntax (via dem TS Grammarware) ■ eine Generierungstechnik für Printer und Parser

► Am besten: normative konkrete Syntax■ EMFText: normative konkrete Syntax for Ecore■ Xtext: normative konkrete syntax for Ecore and OAW

23

TS OWL

TS Grammar-

ware

TS Ecore

OWL EBNF EMOF

Printer Parser

PrinterParser


CASE Data Interchange Format (CDIF)

Folgende Standardgruppen existieren: Zur Defi nition der CDIF-Architektur: • Data Interchange Format - Überblick

• Framework for Modelling and Extensibility Zur Defi nition von Transfer Formaten: • Allgemeine Regeln für Syntax und

Verschlüsselung • OMG IDL Bindings u. a.

Semantisches Inform.- Metamodell: • Foundation Subject Area • Common Subject Area • Data Modeling Subject Area, ...

Präsentations Informations - Meta-Modell: Festhalten von Layout-Information

Quellen: OMG-Dokument ad/98-07-09; http://www.cdif.org

► CDIF ist ein Austauschformat für CASE-Werkzeuge, basierend auf■ Metasprache auf M3: ERD

► Austauschformat einfachen, transparenten Aufbaus zwischen (Modell-)Tools und Repositories

■ hersteller- und methodenunabhängig■ unterstützt die Kooperation zwischen verschiedenen Tools und Projekten


CDIF-Modellbeschreibung eines DFD

Den Objekten eines Datenfl ußdiagramms (DFD) sind folgende Attibute zuzuordnen (Spezifi kation von DFD in CDIF, textuelle Notation von ERD):

obj_dfd (dataFlowDiagram dfd_title {dfd_element} )

dfd_title (dfdTitle @dfd_title_id dfd_title_name )...dfd_element dfd_bubble |dfd_store | dfd_term | dfd_tb |

dfd_csc | dfd_flow

dfd_bubble (process pt pt @process_id process_name inst_num [process_type] )

@process_id (processID string )process_name (processName string )process_type (processType string )dfd_store (store pt pt store_name inst_num )store_name (storeName string )


Transformative TS-Brücken via CDIF

► TS-Brücken (via CDIF) generieren Parser und Printer► Normative konkrete Syntax in der CDIF-Spezifkation festgelegt

26

ModelsTextuelle

Repräsenta-tionen

Modelle

DFD DFD DFD

Printer Parser

PrinterParser

MOF ERD EMOF

TS MOF TS CDIF TS EMOF

M3

M2

M1


Details - Transformative Brücke CDIF

► CDIF-Brücke defniert eine Textuelle Syntax für ERD (ERD-T)■ normative textuelle Repräsentation (für alle Sprachen auf M2 gleich)

27

DFD-Diagramm

DFD-Textuelle Repräsentation

DFD DFD

Printer

Parser

MOF ERD-TM3

M2

M1

TS MOF TS CDIF


XMI - XML Metadata Interchange Format

► Ziel: anbieterneutrales ofenes Austauschformat für Metadaten/Modelle in verteilten Umgebungen

■ Metasprache MOF ■ generisches „Stream“-Format ■ lose gekoppelte Architektur, einfach für Anbieter zur Verarbeitung in

aktuellen Produkten■ überwindet Lücken zwischen inkompatiblen Tools, Repositories und

Anwendungen

► Stand: OMG-Standard für XML Metadata Interchange (XMI) zwischen Repositories, Tools und Anwendungen Version 2.1 (formal/2005-09-01)

► Allerdings:■ Wegen des Indeterminismus des spannenden Baumes keine volle

Kompatibilität möglich


Transformative TS-Bridges via XML

► XML is a normalized concrete syntax■ Because of trees, a linearized normalized concrete syntax is possible

► Good for exchange!

OWL Modelle

TextuelleRepräsenta-

tionen von OWL in XML

OWL Modelle

OWL OWL DFD

Printer Parser

PrinterParser

OWL XSD EMOF

TS OWL TS XML TS EMOF

M3

M2

M1


XMI: Transformative TS-Brücke

Im allgemeinen Sinne ist XMI eine Brücke zwischen MOF und und anderen TS via XSD/XML

ModelleTextuelle

Repräsenta-tionen von L in

XML

Modelle

L L L

Printer Parser

PrinterParser

MOF XSD EMOF

TS MOF TS XML TS EMOF

M3

M2

M1

XMI


XMI: Transformative TS-Brücke für UML

Meist wird allerdings das nur für UML ausgeprägt. Dann ist XMI eine UML-Brücke

UML Modelle

TextuelleRepräsenta-

tionen von UML in XML

UML Modelle

UML UML UML

Printer Parser

PrinterParser

MOF XSD EMOF

TS MOF TS XML TS EMOF

M3

M2

M1

XMI


Zusammenhang XMI - UML

► XMI liegt ein Metamodell der UML zugrunde, das zweimal, in MOF und XSD, spezifziert wird

■ Zwischen beiden Metamodellen wird ein Sprachabbildung (language mapping) angegeben

■ Aus diesem werden Printer und Parser generiert

ModelleTextuelle

Repräsenta-tionen von L in

XML

UML UML

Printer

Parser

MOF XSD

TS MOF TS XML

M3

M2

M1

Type

Attribute

Association

Type

Attribute

Association


Problem: normativer spannender Baum für Graphmodelle

► UML bzw. MOF sind graphbasiert, XML baumbasiert► XML muss bestimmte Links in Namensreferenzen aufösen

■ Dazu wird über UML oder MOF-Modell ein Spannender Baum gelegt (z.B. entlang der Aggregation)

■ Alle Links, die nicht im spannenden Baum vorkommen, werden mit Namensreferenzen dargestellt, und nicht im XML Baum

► Da der spannende Baum nicht deterministisch ist, entstehen Inkompatibilitäten

Printer

Parser

UML UML

TS MOF TS XML

M2

M1

Type

Attribute

Association

Type

Attribute

Association


Einschub: UML - Metamodell


Von MOF abgeleitete Metamodelle

M3

M2MOF

MOF

CWMUML

<<instanceOf>>


Struktur von UML auf M2

UML Superstructure

UML Infrastructure

<<import>>

UML Infrastructure


Core Package des UML-Metamodells

Quelle: UML 2.0 Infrastructure Specification; OMG Adopted Specification ptc/03-09-15

Basic: Grundkonstukte für XMI Abstractions: abstrakte MetaklassenConstructs: Metaklassen für ooModellierung Primitive Types: vordefiniert im Metamodell


Package Basic: Types


Die abstrakten Metaklassen dienen zum Benennen und zur Typdefinition von Elementen


Package Basic: Classes


Definieren einer Klasse als Typ und Festlegung der weiteren Elemente zur klassenbasierten Modellierung


Package Structure UML 2.0


Enthält alle Packages zur systemstrukturierten und verhaltensorientierten Modellierung


Beispiel einer XMI-Objektinstanz: Kodierung einer UML-Klasse

example

C1

#A1

<?xml version = „2.0"?><!DOCTYPE XMI SYSTEM "uml.dtd"><XMI xmi.version=„2.0"><XMI.Header> <XMI.Metamodel name=„UML“ href=„UML.xml“/> <XMI.Model name=„example“ href=„example.xml“/></XMI.Header><XMI.Content> <Core.Basic.NamedElement.name>example</Core.Basic.NamedElement.name> <Core.Basic.Class>

<Core.Basic.NamedElement.name>C1</Core.Basic.NamedElement.name> <Core.Basic.feature>

<Core.Basic.Property> <Core.Basic.NamedElement.name>A1</Core.Basic.NamedElement.name>

<Core.Sasic.NamedElement.visibility xmi.value=“protected"/></Core.Basic.Property>[<Core.Basic.Operation> ... </Core.Basic.Operation>]

</Core.Basic.feature> </Core.Basic.Class></XMI.Content></XMI>

(ähnliches Beispiel siehe : www.jeckle.de/xmi_ex1.htm)

UML Typen


Transfomation von XMI-basierten Modellen mit XSLT

Quelle: Großmann, A.: XMI für prozedurale Programmstrukturen und Transformation in UML; Diplomarbeit an der Fakultät Informatik der TU Dresden, 2000

Vier EbenenRepository

CASE-Tool (z. B. Rational Rose)

XSLT-Prozessor

PML-DTD

PML-Modellals XMI-Datei

XMI-Export

PML-UML-Abbildung als XSLT-Skript

UML-DTD

UML-Modellals XMI-Datei

XMI-Schnittstelle(Unisys XMI-Plugin)

wird beschrieben durchvalidiert durch validiert durch

wird beschrieben durch

Auf XML-Basis


Datenaustausch zwischen UML und CWM im Kontext von MDA

MOF Metamodell

UML-Metamodell

PIM

CWM

PSMPSM

J2EE/EJBProfi le

CORBA/IDLProfi le

EJBCode

IDLCode

Spezifi schesrelationales

Datenbankmodell

XMI-Dateien

XMI-Dateien

CWM:= Common Warehouse Metamodel

Quelle: Andresen, A.: Komponentenbasierte Software- entwicklung mit MDA; UML und XML;

Hanser Verlag 2003, S. 251

M2

M1

MDA:= Model Driven Architecture

CIM CIMComputation independent model


ADOxx

Integrated Modelling using Transformation-Based Repository Bridges

TrOWLWS

UML, BPMN, DSL…Modelling world

Ontology Reasoning WorldTwoUse“Bridge”

Declarative ConstraintsExpressed in OWL

1. IsModelValid (model, query)

Integrated Modelling based on MOST Integrated Language

2. Transform intgr. model “model” intoOWL only ontology and transform

query into SparQL

3. IsOntologyValid (onto, query)

4. Perform Reasoning onOntology “onto”

5. return ontology result

Modelling World

6. process result backAs model result

7. return model result

0. create integrated model “model”

8. display result on model“E.g. mark invalid objects”

ADOxx

TwoUse

ADOxx as an integrated modelling toolkit

TrOWL as semantic reasoner

+

27

TwoUse (U Koblenz) ist eine Transformationsbrücke zwischen TS ADOxx (BOC Wien) und TrOWL (OWL, Uni Aberdeen)


5.5 Frameworks zur Werkzeug- integration (PCTE)


Portable Common Tool Environment(z. B. PCTE +, HPCTE)

Schnittstellenstandard - unterstützt systemunabhängigen Zugriff auf Werkzeuge (innerhalb von EU-Projekten entwickelt)

Schnittstellenstandard - unterstützt systemunabhängigen Zugriff auf Werkzeuge (innerhalb von EU-Projekten entwickelt)

Quelle: ECMA - Portable Common Tool Environment (PCTE), Abstract Specifi cation; ECMA-149, 2nd Edition, Juni 1993

PCTE User Interface (OSF/Motif)mit Access Control Functions

PCTE Object Management Systemmit Schemadefi nitionen (Objekt - Attribute, Links)

Host Computer Operating System

Distribution and Process Communication

Tool Tool Tool


Technische Merkmale von PCTE

Quelle: http://pi.informatik.uni-siegen.de/pi/hpcte/hpcte.html

PCTE stellt eine Menge hochintegrierter Basisdienste bereit, die eine vielseitige Grundlage für verteilte Software-Entwicklungsumgebungen (SEU) bilden, die auch oft SEU-Frameworks oder Repositories genannt werden. Hauptmerkmale sind:

• verteiltes DBMS basierend auf dem ERM mit Erweiterungen, wie zusammen-gesetzte Objekte, Versionen, Mehrfachvererbung, dynamisch kreierte Sichten, eingebettete Transaktionen usw.

• ein exklusives Ausführungssystem, welches Prozeßhierarchien, Vererbung von offenen Files, Prozeßkommunikation über Pipes und Nachrichtenwarte-schlangen gestattet. Werkzeuge können als Shell-Skript geschrieben und in mehreren Fenstern unterstützt werden.

• verteilte Dienste, d.h. Objektbasis und Prozesse sind transparent verteilt, Re-plikation von Objekten sowie Schema-Management sind ebenfalls dezentrali-siert.

• erweiterbare Sicherheitsmerkmale, wie Vertraulichkeit, geschützte Zugriffs-steuerung für individuelle Objekte, Revisionsfähigkeit.

PCTE ist selbstreferenzierend, das bedeutet, Typen, Prozesse, Teile der Objektba-sis, Nutzer und Nutzergruppen werden einheitlich repräsentiert als Objekte.


PCTE-OMS-Modell (Object Management System)

Quelle: http://gille.loria.fr:7000/Emeraude/emeraude.html

► Das OMS stellt Datentyp- und Datenspeichermöglichkeiten sowie Concurrency-Control-Mechanismen zur Verfügung,

■ defi niert statische Informationen, die in der object base (Repositorium aller persi-stenten Daten) gehalten werden,

■ überwacht Gesamtheit der an verteilten Host verfügbaren Objekte (auch replizierte)

■ liefert Konzepte für die Softwareentwicklung, wie beispielsweise die (Typ-)Verer-bung der objektorientierten Modelle.

► Das OMS ist metamodell-gesteuert. Es enthält Typdefi nitionen, die in Schema Defi nition Sets (SDS, Metamodelle) beschrieben werden:

■ Objekte: Basisentitäten, auf denen Operationen der Werkzeuge ausgeführt werden. Instanzen können Dokumente, Textfi les, Quell- oder Objekt- code, Task aber auch Geräte und Nutzer sein.

■ Links (Assoziationen): gerichtete Beziehungen zwischen (Ursprungs-) und (Ziel-)Objekt (bidirektional)

■ Attribute: beschreiben Objekte und Links näher. Sie enthalten einen bestimmten Wertetyp und können sowohl Schlüssel- als auch normales Attribut sein.


PCTE-OMS Metaschema (Metasprache)

Link-Typ Kategorien: c composition bei Anlegen eines neuen Objekts in Referenz zum existierenden.r reference zwischen Ursprungs- und Zielobjekti implicit kann z.B. reverse link für einen angelegten Link sein s system implicit, automatisch vom System (PCTE-OMS) gesetzt.

sds_object

attribut_type_in-sds

link_type_in_sds

object_type_in_sds

object_type link_type attribut_type

categorystabilitycardinality

type_reference

booleanstring

integerdatatype_reference

ri

i r

ic

ic

ic

ic

.in_sds

type_refence.defi nition

().is_in_sds ().is_in_sds().is_in_sds

.of_type .of_type .of_type.parent_type

.subtype

.key_attribut_of

.in_attribut_set().is_attribute_ofr r


PCTE-Objekt-Strukturen

PCTE Metamodell:

Beispiel-Modell:

object

device

subtype ofexecut. fi les

document

tool user_guide

directory pipe fi lemanaged byspecifi c primitives

User

Document

MailboxSoftware

titleauthorization

email_address

soft-created_by soft

documents

documented_by

writes_in

author_of


Emeraude PCTE FrameworkE

nvi

ron

men

t

Fra

mew

ork

Specifi -cation Tools

DesignTools

CodingTools

TestTools

Integra-tionTools

ValidationTools

VERTICALTOOLS

HORIZONTALTOOLS

Documentation(Text+Graphik)Management

DataManagement

Command Language Interpreter

Confi gurationand VersionManagm.

Public Tool Interface (PTI)

DataIntegration

Service

Presentation Integration Services

ControlIntegrationServices

Platform

Documents

5. Datenbasis (Repositorium) und Austauschformatest.inf.tu-dresden.de/Lehre/WS09-10/sew/slides/sew-05-repository.pdf · DFD DFD Printer Parser M3 MOF ERD-T M2 M1 TS MOF TS CDIF. Prof