III. Software Factories 30. Integration of Tools, Exchange Formats,...

Model-Driven Software Development in Technical Spaces (MOST) © Prof. U. Aßmann

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie

III. Software Factories

30. Integration of Tools, Exchange Formats, LanguageMappings, and Integrated Development Environments

Prof. Dr. Uwe Aßmann

Technische Universität Dresden

Institut für Software- undMultimediatechnik

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

Version 15-0.7, 08.01.16

1) Software Factories

2) Data Integration

3) Exchange Formats

4) Appendix1) ECMA-Referenzmodell

2) Frameworks zur Werkzeug- integration (PCTE)

© P

rof.

U. A

ßm

ann

2 Model-Driven Software Development in Technical Spaces (MOST)

References

► ECMA, Reference Model for Frameworks of Software Engineering Environments,Technical Report 55, 3rd Edition, Juni 1993

– http://www.ecma-international.org/publications/fles/ECMA-TR/TR-055.pdf

► Richard C. Holt, Andreas Schürr, Susan Elliot Sim, and Andreas Winter. GXL: A graph-based standard exchange format for reengineering. Science of ComputerProgramming, 60(2):149-170, April 2006.

– http://www.gupro.de/GXL/Publications/publications.html

http://www.ecma-international.org/publications/files/ECMA-TR/TR-055.pdf

© P

rof.

U. A

ßm

ann


The Book of the MOST Project (2008-11)



30.1 Software Factories with HeterogeneousRepositories

© P

rof.

U. A

ßm

ann


Q13: A Software Factory's Heart: the Multi-TS Megamodel

Mega- and MacromodelsMega- and Macromodels

Method EngineeringMethod Engineering

Model ManagementMapping, Transf., Composition


Technical Space Bridges


Technical SpaceTechnical Space

Pattern Languages

Pattern Languages

Model AnalysisQuerying, Interpretation


Metapyramid (Metahierarchy) for Token ModelingMetapyramid (Metahierarchy) for Token Modeling

Software Factory

HeterogeneousMulti-repository Megamodel

Mega- and MacromodelsMega- and Macromodels

Method EngineeringMethod Engineering





Technical SpaceTechnical Space

Pattern Languages

Pattern Languages



Metapyramid (Metahierarchy) for Token ModelingMetapyramid (Metahierarchy) for Token Modeling

© P

rof.

U. A

ßm

ann


Software Factories

► A software factory is a modeling environment for the production of software productlines.

■ The software factory maintains a set of repositories for models in differentlanguages and connects them to one macromodel:

■ Mono-repository: all models of the megamodel in one repository, requiringone technical space

■ Multi-repository: models in different repositories■ Heterogeneous multi-repository: models in different repositories, with

many technical spaces

► Software factories are big integrated MDSD environments coupling many tools andmaterials

■ A pure software factory creates software with software. Example: UML tool, SysML tool

■ A systems software factory creates a system in soft- and hardware (withsoftware)

. Example: PreeVision, ASCET, Cadence Silicon Compiler

► Often, multi-repository software factories result from data connection of alreadyexisting tools (tool integration)



30.1.1 Concepts of Tool Integration for SoftwareFactories

© P

rof.

U. A

ßm

ann


Integration of Tool Suites

Tool Suite 1 Tool Suite 2

Tool Suite 3 Tool Suite 4

Document type set 1 (D 1)




Quelle : [ ES89, 6, S. 11 ]

© P

rof.

U. A

ßm

ann


Tool Integration in 4 Dimensions

Process Integration

ControlIntegration

User Interface- Integration

MDSD Tool Chain

Data Integration

Data exchange

Dataconnection

Datasharing

Embedding into a workflow (e.g., of a toolautomaton)

Integration into adefined softwaredevelopment process

Quelle: [ Balzert-II 3, S. 605 ]



30.2 Data Integration

© P

rof.

U. A

ßm

ann


Levels of Data Integration

Integration Kind Schema Characteristics

Black-box-Integration

(weak)

Grey-box-Integration(medium)

White-box-Integration

Data sharing(strong)

CASEtool

Repo-sitoryDateien

check out

CASEtool

CASEtool

Daten Daten

check in

CASEtool

CASEtool

Daten-schema

Daten

...

● Too works isolated on own data ● Repositoriy coordinates data with

check in and check outl

● Separate repositoriy, but common accessinterfaces

● Access layer to repositories

● Definition of uniform data schema (materialmetamodels) for all tools

● Integration of data schemata of tools by● Role-based integration● Inheritance-based integration

[Balzert-II, S. 608]

...

Repository

Repository

© P

rof.

U. A

ßm

ann


a) Data Exchange (Simple)

DFD Editor Mask Editor Mask Generator

datum maskedatum datum maske

programm

tool1 tool2 tool3

Repository 1 Repository 2 Repository 3

Quelle: nach [ HMF. S. 196 ]

► No common data, high cost for exchange

► Exchange with Streams and Data-Flow Architecture (Example: UNIX shell)

– Queries flter data, transformations change data

– Data formats are defned in an exchange language

► Tools are rather independent

© P

rof.

U. A

ßm

ann


b) Data Connection with Systematic Data Exchange(Transformation Bridges)

DFD Editor Masken Editor

datum maskedatum

tool1 tool2

Repository 1 Repository 2

► Data connection (Datenverbindung) relies on the defnition of mappings between the data schemata(material metamodels)

► Automated data exchange in standardised exhange formats (Exchange formaten (z. B. ASN, XMI, JSON,CDIF, XML)

– Automation relies on mappings between the material metamodels► Transformation bridge: a prettyprinter transforms the internal representation of a repository into an

external exchange formant

■ Parser read the exchange format again and transform it into the internal representaiton ofthe other repository

■ Query and transformation languages flter the data

printer parser

Bridgen-Generator

© P

rof.

U. A

ßm

ann


c) Data Connection with Incremental Data Exchange(Adapter Bridges)

DFD Editor Mask Editor

date maskdate

tool1 tool2

Repository 1 Repository 2

► An Adapter Bridge is a layer between two repositories allowing for incremental access from one to the other

■ Transformation of data incrementally with each access■ Direct transformation without exchange format

Adapter layer

Adapter Bridge Generator

© P

rof.

U. A

ßm

ann


Current Exchange Formats

Exchange format: standardized for the exchange of data between tools, also of different vendors

► Comma-separated values (CSV): simple text-based exchange format for tools on relation, text algebra,and tables (Excel, TeX, ...)

■ No metalanguage but simple table schema http://tools.ietf.org/html/rfc4180

■ http://en.wikipedia.org/wiki/Comma-separated_values

► CASE Tool Data Interchange Format (CDIF) - metalanguage ERD for data defnition as well as

■ Data Flow Model, State Event Model, Object Oriented Analysis and Design

■ http://www.ecma-international.org/publications/fles/ECMA-ST/Ecma-270.pdf

► XML Metadata Interchange (XMI) for exchange of UML-diagrams in XML-format■ Meta Object Facility (MOF) as metalanguage■ http://www.omg.com/technology/documents/formal/xmi.htm

► ASN.1 Standard is a metalanguage based on BNF

■ http://de.wikipedia.org/wiki/Abstract_Syntax_Notation_One

► RDF/RDFS Resource Description Format – Models as graphs, stored in elementary tripelshttp://www.w3c.org

► GXL Graph Exchange format: Open Source Format for exchange of graphs

■ http://www.gupro.de/GXL/

© P

rof.

U. A

ßm

ann


d) Data Sharing (With Common Repository)

tool1tool2

Customer Responsible.Person Person

transienteObjekte

transienteObjekte

MetaclassCustomer

Metaclass PersonMetaclassResponsible.

Metadata Repository

Editor 1 Editor 2

Quelle: Platz, D.,Kelter, U.: Konsistenzerhaltung of Fensterinhalten in SEU; http://pi.informatik.uni-siegen.de

► With data sharing (Datenteilung) all tools share common data with a uniform schema(material metamodel)

► Metaclass mappings control the integration of the repositories and metamodels



30.3 Data Connection with Exchange Formats

© P

rof.

U. A

ßm

ann


Exchange Formats use Normative Concrete Syntax

► Data Connection (Datenverbindung) between repositories relies on a semanticrelationship of the data

■ Identical M2-Metamodel■ Metamodels can be mapped isomorphically (1:1) (language mapping)■ Metamodels can be mapped homomorphically (n:m, n:1), e.g., language A is

a subset of language B or vice versa

► Exchange format are text-based with a normative concrete syntax, because the syntaxis normed (standardized) and not user-centered

■ Grammarware, XMLWare are the most popular technical spaces■ From the language mappings, parsers and prettyprinters are generated

© P

rof.

U. A

ßm

ann


Transformative TS-Bridges with Concrete Syntax

► A transformative Technical-Space-Bridge (TS-Bridge, TS bridge) offers■ An exchange format in normative concrete syntax (e.g., via TS

Grammarware) ■ A generation technique for printers and parsers

► Techniques for normative concrete Syntax■ Text: EMFText: normative concrete syntax for Ecore/EMOF■ Text: Xtext: normative concrete syntax for Ecore/EMOF■ CDIF: normative concrete syntax für ERD■ JSON: text-based normative concrete syntax

19

TS OWLTS OWL

TS Grammar-

ware

TS Grammar-

ware

TS EcoreTS

Ecore

OWLOWL EBNFEBNF EMOFEMOF

PrinterPrinter ParserParser

PrinterPrinterParserParser

© P

rof.

U. A

ßm

ann


Exchange Format CDIF (CASE Data Interchange Format)Example: Specifcation of DFD

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 )

► CDIF is a historic exchange format for CASE tools based on metalanguage ERD► The standard CDIF uses RTG for the def inition of types, a textual notation of ERD

(ERD-Text)► Example: Specif ication of DFD in ERD-RDT (keywords in boldface, def ined non-

terminals in typewriter, used non-terminals in italics):

© P

rof.

U. A

ßm

ann


Exchange Format CDIF

► CDIF defnes a normative textual syntax für ERD (ERD-RTG)

21

DFD-DiagramDFD-Diagram DFD-textualRepresentationDFD-textual

Representation

DFDDFD DFDDFD

PrinterPrinter

ParserParser

MOFMOF ERD-RTGERD-RTGM3

M2

M1

TS MOF TS CDIF



30.3.2 Transformation Bridges between Technical Spaces

© P

rof.

U. A

ßm

ann


Transformative TS-Bridges via CDIF

► TS-Bridges (via CDIF) generate parser und printer► Here: TS MOF to EMOF

ModelsModelsTextual

Representa-tionen

TextualRepresenta-

tionenModelsModels

DFDDFD DFDDFD DFDDFD



MOFMOF ERD-RTGERD-RTG EMOFEMOF

TS MOF TS CDIF TS EMOF

M3

M2

M1

© P

rof.

U. A

ßm

ann


Transformative TS-Bridges via XML

► XML is a normalized concrete syntax

– Again, because of indeterministic spanning trees, a linearizednormalized concrete syntax is possible

► Hoever, good for exchange!

DFD ModelsDFD ModelsTextual

Representa-tionen of DFD

in XML

TextualRepresenta-

tionen of DFDin XML

DFD ModelsDFD Models




OWLOWL XSDXSD EMOFEMOF

TS OWL TS XML TS EMOF

M3

M2

M1

© P

rof.

U. A

ßm

ann


Transformative TS-Bridges with JSON

► JSON (Java Script Object Notation) has established as simple exchange format forrecord trees (attributed trees) http://www.json.org/ http://www.ietf.org/rfc/rfc4627.txt?number=4627

► Basically, it is like XML, but better readable

DFD ModelsDFD ModelsTextual

Representa-tionen of DFD

in JSON

TextualRepresenta-

tionen of DFDin JSON

DFD ModelsDFD Models




MOFMOF JSONJSON EMOFEMOF

TS MOF TS JSON TS EMOF

M3

M2

M1

http://www.json.org/

http://www.ietf.org/rfc/rfc4627.txt?number=4627

© P

rof.

U. A

ßm

ann


Exchange Format XMI XML Metadata Interchange Format

► XML Metadata Interchange (XMI) is an OMG-Standard for an exchange format ■ Version 2.1 (formal/2005-09-01)■ Metalanguage MOF ■ generic „Stream“ format

► Problem:■ Graph-based models must determine a spanning tree (for the XML link tree)■ There are several spanning trees (Indeterminism)■ No full compatibility between tools!

© P

rof.

U. A

ßm

ann


XMI: Transformative TS-Bridge

XMI is a TS-Bridge between the TS MOF and other TS via XSD/XML

Models ModelsTextual

Repräsenta-tionen of L in

XML

TextualRepräsenta-tionen of L in

XMLModelsModels

LL LL LL



MOFMOF XSDXSD EMOFEMOF

TS MOF TS XML TS EMOF

M3

M2

M1

XMI

© P

rof.

U. A

ßm

ann


XMI: Transformative TS-Bridge for UML

► Often, XMI is only used for UML. Then, XMI is an UML-Bridge

UML ModelsUML ModelsTextual

Representa-tionen of UML

in XML

TextualRepresenta-

tionen of UMLin XML

UML ModelsUML Models

UMLUML UMLUML UMLUML



MOFMOF XSDXSD EMOFEMOF

TS MOF TS XML TS EMOF

M3

M2

M1

XMI

© P

rof.

U. A

ßm

ann


Relation XMI – UML:Language Mappings

► XMI has as a basis the UML metamodel specifed both in MOF und XSD■ Between these metamodel a bidirectional, isomorphic language mapping

is given■ Printer and parser are generated from this mapping

Models ModelsTextual

Representa-tionen of L in

XML

TextualRepresenta-tionen of L in

XML

UMLUML UMLUML

PrinterPrinter

ParserParser

MOFMOF XSDXSD

TS MOF TS XML

M3

M2

M1

Type

Attribute

Association

Type

Attribute

Association

© P

rof.

U. A

ßm

ann


Remember: Classes and Properties in UML-Core

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

Metamodel for Class and Property

© P

rof.

U. A

ßm

ann


Example of an XMI-Instance: Coding of an UML-Class

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>

(adopted from: www.jeckle.de/xmi_ex1.htm)

UML Metaclasses

© P

rof.

U. A

ßm

ann


Problem: Normative Spanning Tree for Graph Models

► UML and. MOF are graph-based, while XML is based on link trees

► XML must resolve some links as name references (i.e., revert name analysis)■ For the UML or MOF-Model, a spanning tree must be found (e.g., along

aggregations)■ All links not in this spannign tree are represented by name references

(secondary links), but not in the XML tree

► Spanning trees are indeterministic. Thus different linearizations for one graph modelpossible

PrinterPrinter

ParserParser

UMLUML UMLUML

TS MOF TS XML

M2

M1

Type

Attribute

Association

Type

Attribute

Association

© P

rof.

U. A

ßm

ann


TwoUse“Bridge”

ADOxx

Example: Transformation Bridge Between ADO und OWL

TrOWLWS

UML, BPMN, DSL…Modelling world

Ontology Technical Space (Reasoning World)

Declarative ConstraintsExpressed in OWL

1. IsModelValid (model, query)

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

ADO Technical Space (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

ADO as an integrated modelling toolkit

TrOWL as semantic reasoner

+

TwoUse (U Koblenz) is a transformation bridge between TS ADO (BOC Wien) and TrOWL(OWL, Uni Aberdeen)

Exchange format: OWL

© P

rof.

U. A

ßm

ann


What did we learn?

► Tools can be integrated via

– Repository integration (data sharing)

– Stream-based exchange

– Datenfuss-gesteuerte

► Software Factories (Software MDSD tools, System Engineering tools) are composedfrom simpler modeling tools and their materials

► This notion of “software factory” is due to Prof. Hartmut Fritzsche.

© P

rof.

U. A

ßm

ann


The End

► Why is data sharing the fastest way to integrate tools?

► Explain different forms of language mappings. What is mapped to each other? ■ What is an isomorphic mapping? A homomorphic mapping?

► Compare JSON with XML. What is different, what is similar?

► Explain, why a tree-based exchange format such as XML, has advantages over EBNFbased exchange formats.

► Explain, why XML is not perfect as exchange format.



30.A.1 Beispiel einer Referenzarchitektur für Werkzeug-Umgebungen: Das ECMA Referenzmodell für SEU

.. Der ECMA-Toaster

© P

rof.

U. A

ßm

ann


Standardisierungsorganisation European Computer Manufacturing Association (ECMA)

► Weltweite Normierung der Informationstechnologie und Nachrichtentechnik

– Mehr als 365 ECMA-Standards

– 2/3 sind als internationale Standards und/oder technische Reportsangenommen worden.

► Ziele:

– Zusammenarbeit mit nationalen, europäischen und internationalenNormierungsorganisationen über die Standardisierung ofKommunikationstechnologien (ICT) und Verbraucherelektronik (CER).

– korrekten Gebrauch of Standards anregen und kontrollieren.

– Veröffentlichung of Standards und technischer Reports, Unterstützungihrer Verbreitung auch in elektronischer Form

► ECMA hat u. a. folgende Technischen Ausschüsse:

– TC 32: Kommunikation, Netze und Systemverbindungen

– TC 39: Programmieren und Script-Sprachen

– TC 43: Universal 3D (U3D)

– TC 12: Sicherheit

Quelle: http://www.ecma-international.org/

© P

rof.

U. A

ßm

ann


ECMA-Referenzmodell („ECMA Toaster“)

Backplane: Object Management Services (Repository)

Underlying:Communication Services

Process Management Services

Frontplane: User Interface Services

Tool Slots

Quelle: ECMA, Reference Model for Frameworks of Software Engineering Environments, Technical Report 55, 3rd Edition, Juni 1993http://www.ecma-international.org/publications/files/ECMA-TR/TR-055.pdf

+ Policy Enforcement Services+ Framework Administration + Configuration Services

► Der ECMA Toaster nutzt eine Service-orientierte Architektur (SOA), kann alsoverteilt sein

► Seine Dienste sind mehr oder weniger in jeder SEU vorhanden

© P

rof.

U. A

ßm

ann


Sichten auf Dienste des ECMA-Referenzmodells

konzeptionelle Sicht beWritet die Semantik (Funktionalität), ohne Imple- tierung oder Verfügbarkeit für den Nutzer zu beachten

externe Sicht beWritet die externe Nutzung des Dienstes durch andere Dienste bzw. durch Werkzeuge od. den Nutzer

interne Sicht beWritet die spezifische implementation (Betriebs- system, andere Tools) für die Dienstausführung

Sicht auf Operationen führt die Menge of Operationen eines Dienstes auf, die zur Erreichung der Funktionalität (konzeptionelle Sicht) benötigt wird

Sicht auf Typen beWritet das Datenmodell des Dienstes einschließ- lich der Informationen über dieses Datenmodell (Metamodell)

Sicht auf Regeln beWritet Regelmenge, die mögliche Menge der Ope- rationen (Sicht auf Operat.) und annehmbare Zustände der Daten definiert

Sicht auf Dienst-zu- anhand typischer Beispiele wird gezeigt, wie einDienst-Beziehungen Dienst mit einem anderen kommunizieren kann

© P

rof.

U. A

ßm

ann


ECMA BenutzungsschnittstelleUSER INTERFACE SERVICES

ECMA stellt eine Reihe of UI-Diensten (services, Schnittstellen) zur Verfügung, die zurGewährleistung der Benutzungsschnittstellen-Integration und der konsistentenBedienung of Anwendungen benötigt werden. ► User Interface Metadata Service dient der Definition, Steuerung und Hand-

habung of Schemata zur Unterstützung der Benutzungsschnittstelle► Session Service gewährleistet volle Funktion, unabhängig of Nutzer oder

Hardwareumgebung ► Security Service gewährleistet Sicherheitsanforderungen, wie

Nutzerauthentifikation, Dunkelsteuerung unbenutzbarer Funktionen u. a.► Profile Service gestattet mögliche Veränderungen, wie z. B. Systemeinstellungen

(Farbe), Menge zu verwendender Werkzeuge u.a.► User Interface Name and Location Service stellt fest, wer sich wo zum System

Zutritt verschafft hat (logging in)► Internationalization Service stellt nationale Besonderheiten (z. B. Zeichensätze,

Datumsformate) zum Zugriff auf das Rechnersystem bereit und gewährleistet ihreKonvertierbarkeit zwischen unterschiedlichen Ländern.

© P

rof.

U. A

ßm

ann


ECMA ProzessverwaltungProcess Management Services

Die Process Management Services defnieren und organisieren die Ausführung aller Werkzeuge:

► Process Defnition Service defniert aus den im Repository gespeicherten Projektdaten die Bedingungenzur Ausführung neuer Aktivitäten

► Process Control Service steuert Prozesse im allgemeinen auf dem Niveau eines bestimmtenVorgehensmodells zur Beeinfussung anderer Prozesse, wodurch der Nutzer entsprechend seiner roleunterstützt wird

► Process Enactment Service unterstützt und bietet Möglichkeiten der Steuerung vorher defnierterAktivitäten (Analyse-, Hilfe-, Simulationsfunktionen)

► Process Visibility and Scoping Service legt zum Zwecke der Kommunikation und KoordinationSichtbarkeit, Zeitpunkt und Ort of Aktivitätsteilen für andere Aktivitäten fest

► Process State Service sammelt und wertet Ereignisse of Aktivitäten während ihrer Ausführung aus, diefür die Koordination und spätere Entscheidungsplanung anderer Projektaktivitäten notwendig sind

► Process Ressource Management Service verwaltet das Festlegen of Ressourcen zur Ausführungdefnierter Prozesse für Werkzeuge und Nutzer

© P

rof.

U. A

ßm

ann


ECMA Werkzeugdienste (Tool Services)

► Werkzeuge können in den ECMA Toaster eingesteckt werden bzw. ausgetauscht werden

– Die gesamte Toolmenge soll nach außen hin durch eine einzige Schnittstelle repräsentiert werden.

– Die Menge der Tools soll den Softwareentwicklungsprozess vollständig abdecken.

► Die Werkzeuge kommunizieren über den Communication Service oder Object Management Service

► Wenn Werkzeuge in die SEU integriert werden, ist zu prüfen, ob sie Frameworkdienste bieten.

– Wenn ja, ist zu entscheiden, diese Dienste weiterhin separat zu ermöglichen oder doch auf die Dienste des SEU-Frameworks überzugehen.

► Um für alle Werkzeuge ein gleiches Erscheinungsbild zu erhalten, müssen Basisdienste und Dienste eines SEU-Framework nach standardisierten Vorschriften realisiert werden.

© P

rof.

U. A

ßm

ann


ECMA Repository (Repositorium)Object Management Services

Die Object Management Services dienen der Defnition, der Speicherung, derHandhabung, der Verwaltung und dem Zugriff auf Objekte/Dokumente (Dateien,Programme, Bibliotheken, Projekte, Geräte usw.):

► Metadata Service gestattet die Defnition, Steuerung und Handhabung of Schemataund sonstigen Metadaten (Refektion, Introspektion)

► Data Storage and Persistence Service unterstützt das persistente Anlegen undSpeichern of Objekten nach der MetadatenbeWriteung

► Relationship Service erlaubt die Defnition und Handhabung of Beziehungen zwischenObjekten und Objekttypen.

► Derivation Service (Bau-Management) legt die Wege fest, welche Objekte of anderenabgeleitet sind (z. B. Generation Objektcode aus Quellcode ähnlich Make-Files).

► Concurrency Service sichert den gleichzeitigen Zugriff für Nutzer und Prozesse zumgleichen Objekt der Repository (Transaktionen, Synchronisation)

► Version Service unterstützt das Anlegen, Zugreifen und Verbinden of Objekt- undKonfgurationsversionen der SEU.

© P

rof.

U. A

ßm

ann


ECMA: Weitere Services

► Die Policy Enforcement Services sind für Sicherheitsaspekte, Integritätsüberwachung undVerwaltungsfunktionen zuständig:

– Mandatory Confdentiality Service legt auf eigenen Wunsch Zugriffsrechte undSicherheitsanforderungen (geheim, str. geheim) für Objektinfomationen fest.

– Mandatory Integrity Service gestatten den Schutz of SEU-Objekten vor unauthorisiertenÄnderungen, z. B. Eintragung "read only"usw.

– Mandatory Conformity Service überwacht alle Aktivitäten zur Einhaltung ofKonformitätsanforderungen, die z.B. aus der Qualitätssicherung stammen.

► Die Communication Services dienen der Kommunikation zwischen Werkzeugen, zwischen Basisdiensten sowieDiensten verschiedener SEU.

– Basismechanismen sind Nachrichten (Punkt-zu-Punkt, Broadcast, Multicast), Betriebs-systemaufrufe, Remote Procedure Calls und der Datenaustausch

► Die Framework Administration und Confguration Services übernehmen die sorgfältige Installation der SEUund ihre laufende Pfege u.a.:

– Tool Registration Service übernimmt das An- und Abmelden neuer Tools.

– User Administration Service unterstützt das An- und Abmelden of Nutzern zum System!

© P

rof.

U. A

ßm

ann


ECMA Toaster: Abhängigkeiten zwischen Diensten

UserInterfaceMetadataService

UserAssistance

Service

PresentationService

ProfileService

ToolService

SessionService

SecurityService

User Admi-nistrationService

Internationali-zation Service

ToolRegistration

Service

MandatoryConformity

Service

MandatoryIntegrityService

MandatoryConfidentiality

Service



30.A.2 Ein Metamodellgesteuertes Framework zurWerkzeugintegration (PCTE)

Mit eigenem Technikraum und Metasprache PCTE-OBS

http://ieeexplore.ieee.org/iel3/2107/7595/00313508.pdf?arnumber=313508

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.8315&rep=rep1&type=pdf

http://ieeexplore.ieee.org/iel3/2107/7595/00313508.pdf?arnumber=313508

© P

rof.

U. A

ßm

ann


Portable Common Tool Environment(PCTE+, HPCTE)

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

PCTE User Interfacemit Access Control Functions

PCTE Object Management System (OMS)metamodellbasiert

Host Computer Operating System

Distribution and Process Communication

Tool Tool Tool

► PCTE ist eines der historisch ersten metamodellgesteuerten Werkzeugintegrationsframeworks

► PCTE erfüllt den Schnittstellenstandard der ECMA - unterstützt systemunabhängigen Zugriff aufWerkzeuge und Repository

© P

rof.

U. A

ßm

ann


Technische Merkmale of 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

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

• ein exklusives Ausführungssystem, welches Prozeßhierarchien, Vererbung of 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 of Objekten sowie Schema-Management sind ebenfalls dezentrali-siert.

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

© P

rof.

U. A

ßm

ann


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,

– def iniert statische Informationen, die in der object base (Repositorium aller persi-stenten Daten) gehalten werden,

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

► Das OMS ist metamodell-gesteuert. Es enthält Typdef initionen, die in Schema Def inition Sets (SDS, Metamodellen) beschrieben werden:

– Objekte: Entitäten, auf denen Operationen der Werkzeuge ausgeführt werden. Instanzen können Dokumente, Textf iles, Quell- oder Objektcode, Task aber auch Geräte und Nutzer sein.

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

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

► Die DDL PCTE-OMS ist geliftet (selbstreferenzierend, in sich selbst spezif iziert, DDL ist geliftet als Metasprache)

© P

rof.

U. A

ßm

ann


PCTE-OMS Metasprache ist eine Erweiterung of ERD(Vererbung, Komposition)

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.def inition

().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_of

r r

© P

rof.

U. A

ßm

ann


PCTE-Objekt-Strukturen mit erweitertem ERD

PCTE DDL Metamodell (M2):

Beispiel-Modell (M1):

object

device

subtype ofexecut. f iles

document

tool user_guide

directory pipe f ilemanaged byspecif ic primitives

User

Document

MailboxSoftware

titleauthorization

email_address

soft-created_by soft

documents

documented_by

writes_in

author_of

© P

rof.

U. A

ßm

ann


Emeraude PCTE Framework

En

viro

nm

ent

Fra

mew

ork

Specif i-cation Tools

DesignTools

CodingTools

TestTools

Integra-tionTools

ValidationTools

VERTICALTOOLS

HORIZONTALTOOLS

Documentation(Text+Graphik)Management

DataManagement

Command Language Interpreter

Conf igurationand VersionManagm.

Public Tool Interface (PTI)

DataIntegration

Service

Presentation Integration Services

ControlIntegrationServices

Platform

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=182066http://www.springerlink.com/content/g111t41326211512/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=182066

http://www.springerlink.com/content/g111t41326211512/

© P

rof.

U. A

ßm

ann


More PCTE Implementations

► PACT PCTE Implementation

– Thomas, Ian. Tool integration in the pact environment. In Proceedings of

the 11th International Conference on Software Engineering, pages 13-22, May 1989.

► HPCTE implementation of University of Siegen

– Java API

– Supports views on the repository

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

III. Software Factories 30. Integration of Tools, Exchange Formats,...

Documents

Transcript of III. Software Factories 30. Integration of Tools, Exchange Formats,...