5. Datenbasis (Repositorium) und...
Transcript of 5. Datenbasis (Repositorium) und...
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
SEW, © Prof. Uwe Aßmann 3
5.1 Ziele und Aufgabender Datenbasis (Repositoriums)
Prof. U. Aßmann, SEW 4
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
Prof. U. Aßmann, SEW 5
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
Prof. U. Aßmann, SEW 6
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
Prof. U. Aßmann, SEW 7
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
SEW, © Prof. Uwe Aßmann 8
5.2 Architektur von Repositories
Prof. U. Aßmann, SEW 9
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
Prof. U. Aßmann, SEW 10
Grobarchitektur bei Datenteilung (Metamodellgesteuertes Repositorium
Tools
Repositorium
Daten-basis desProjektes
Metadaten-verwaltungssystem
INTERFACETool-Export-Import
Schnittstelle
persistente Objekt-
speicherung
Operationen zurDatenverwaltungund -manipulation
Prof. U. Aßmann, SEW 11
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
SEW, © Prof. Uwe Aßmann 12
5.3 Beispiele
Prof. U. Aßmann, SEW 13
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
Prof. U. Aßmann, SEW 14
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
Prof. U. Aßmann, SEW 15
AD/CYCLE-Architektur (IBM)
User Interface
Workstation Service
Work Management
Tool Services
AD Information Model
LibraryService
RepositoryService
ADPlatform
ADTools
Quelle: [1, S. 141]
Prof. U. Aßmann, SEW 16
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
Prof. U. Aßmann, SEW 17
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)
Prof. U. Aßmann, SEW 18
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)
Prof. U. Aßmann, SEW 19
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>>
Prof. U. Aßmann, SEW 20
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>>
SEW, © Prof. Uwe Aßmann 21
5.4 Austauschformate
Einsatz in Transformations-Brücken zwischen Repositorien
Prof. U. Aßmann, SEW 22
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
Prof. U. Aßmann, SEW 23
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
Prof. U. Aßmann, SEW 24
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
Prof. U. Aßmann, SEW 25
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 )
Prof. U. Aßmann, SEW 26
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
Prof. U. Aßmann, SEW 27
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
Prof. U. Aßmann, SEW 28
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
Prof. U. Aßmann, SEW 29
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
Prof. U. Aßmann, SEW 30
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
Prof. U. Aßmann, SEW 31
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
Prof. U. Aßmann, SEW 32
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
Prof. U. Aßmann, SEW 33
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
SEW, © Prof. Uwe Aßmann 34
Einschub: UML - Metamodell
Prof. U. Aßmann, SEW 35
Von MOF abgeleitete Metamodelle
M3
M2MOF
MOF
CWMUML
<<instanceOf>>
Prof. U. Aßmann, SEW 36
Struktur von UML auf M2
UML Superstructure
UML Infrastructure
<<import>>
UML Infrastructure
Prof. U. Aßmann, SEW 37
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
Prof. U. Aßmann, SEW 38
Package Basic: Types
Quelle: UML 2.0 Infrastructure Specification; OMG Adopted Specification ptc/03-09-15
Die abstrakten Metaklassen dienen zum Benennen und zur Typdefinition von Elementen
Prof. U. Aßmann, SEW 39
Package Basic: Classes
Quelle: UML 2.0 Infrastructure Specification; OMG Adopted Specification ptc/03-09-15
Definieren einer Klasse als Typ und Festlegung der weiteren Elemente zur klassenbasierten Modellierung
Prof. U. Aßmann, SEW 40
Package Structure UML 2.0
Quelle: UML 2.0 Infrastructure Specification; OMG Adopted Specification ptc/03-09-15
Enthält alle Packages zur systemstrukturierten und verhaltensorientierten Modellierung
Prof. U. Aßmann, SEW 41
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
Prof. U. Aßmann, SEW 42
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
Prof. U. Aßmann, SEW 43
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
Prof. U. Aßmann, SEW 44
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)
SEW, © Prof. Uwe Aßmann 45
5.5 Frameworks zur Werkzeug- integration (PCTE)
Prof. U. Aßmann, SEW 46
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
Prof. U. Aßmann, SEW 47
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.
Prof. U. Aßmann, SEW 48
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.
Prof. U. Aßmann, SEW 49
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
Prof. U. Aßmann, SEW 50
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
Prof. U. Aßmann, SEW 51
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