3. Architektur von Software-...

SEW, © Prof. Uwe Aßmann 1

3. Architektur von Software- Entwicklungsumgebungen

Prof. Dr. Uwe Aßmann

Technische Universität Dresden

Institut für Software- und Multimediatechnik

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

Version 08-0.7, 27.11.08

1) Werkzeugintegration

2) Architektur von SEU

3) ECMA-Referenzmodell

4) Efektkategorien von Werkzeugen und Komposition mit Werkzeug-Blutgruppen

5) Werkzeugobjekte (tool objects)

6) Graph-Logik-Isomorphismus

Prof. U. Aßmann, CBSE 2

Literatur

► Johannes Siedersleben. Moderne Softwarearchitektur - Umsichtig planen, robust bauen mit Quasar, dpunkt-Verlag, 2004, Heidelberg

■ www.openquasar.de

► 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

http://www.openquasar.de/


3.1 Konzepte der Werkzeug- integration


Integrierter Werkzeugsatzzur inkrementellen Softwareentwicklung

Werkzeugsatz 1 Werkzeugsatz 2

Werkzeugsatz 3 Werkzeugsatz 4

Dokumententyp 1 (D 1)




Quelle : [ ES89, 6, S. 11 ]


Werkzeugintegration

Benutzerschnitt-stellen-Integration

CASE-Werkzeug

Prozess-Integration

Steuer-Integration

Daten-Integration

Daten-austausch

Daten-verbindung

Daten-teilung

Verbindung möglicherWerkzeugfunktionen durch:

• Interprozesssteuerung (Inf.austausch direkt zwischen Werkzeugen)• Metasteuerung (Aufruf über Metaagenten)

Werkzeugintegration zur Unterstützung eines definierten Prozesses/ Vorgehens bestehend aus mehreren Schritten

Forderungen: • Interoperabilität - u. U. Formatwandlung• Redundanzfreiheit - Einmalspeicherung• Datenkonsistenz - Persistenz• Synchronisation - Abstimmung des Werkzeugzugriffs

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

Zusammenarbeit unter einheit-licher Benutzungsoberfläche

Zusammenarbeit mehrerer Werkzeuge mit gleicher Präsentation, gleichem Verhalten und Interaktionsformen


Werkzeuge ohne Datenintegration

DFD Editor Masken Editor Masken Generator

datum maskedatum datum maske

programm

wz1 wz2 wz3

DB1 DB2 DB3

Quelle: nach [ Hesse 4. S. 196 ]

► .. benötigen hohen Aufwand zum Austausch von Daten


Datenverbindung/Datenaustausch

DFD Editor Masken Editor

datum maskedatum

wz1 wz2

DB1 DB2

Datenverbindung ist die Einführung semantischer Beziehungen zwischen Teilen von Datenbeständen, die von verschiedenen Werkzeugen bereit gestellt werden.

Datenaustausch ist die Übertragung von strukturierten Informationen zwischen Werkzeugen in gegenseitig verständlicher Form (z. B. XMI, CDIF).


CASE Austauschformate

Quelle: http://www.omg.com/technology/documents/formal/xmi.htm

Austauschformat: Hersteller- und methodenunabhängigen (Meta-)Datenkonzept für die Modellierung von Austauschdaten zwischen CASE sowie die Spezifkation von Repositories► XML Metadata Interchange (XMI)

■ Nutzung der Meta Object Facility (MOF) als Metamodell (u.a. Basis des Austausches von UML-Diagrammen)

► CASE Tool Data Interchange Format (CDIF) - MetaModelle in ERD für■ Data Flow Model, Data Defnition, State Event Model ■ Object Oriented Analysis and Design■ Presentation Location and Connectivity Subject ■ http://www.ecma-international.org/publications/fles/ECMA-ST/Ecma-

270.pdf

► Universal Object Language UOL■ Beschreibung von UML-Modellen, Basis Eifel

Einigung auf gemeinsame Weiterentwicklung und Einmündung aller Bemühungen in XMI


Datenteilung (Shared Repository)

wz1 wz2

Privatkunde Zeichngsber.Person Person

transienteObjekte

transienteObjekte

KlassePrivatkunde

Klasse PersonKlasseZeichngsber.

OOA-Dokument-WurzelArtefaktbank

Editor 1 Editor 2

Vererbung Vererbung

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

► Werkzeuge greifen direkt auf Daten zu, die in einem gemeinsam verfügbaren Speicher (Repository) nach einem einheitlichen Datenmodell abgelegt sind.

► Repository (Repositorium, Datenbasis, Objektbank, Artefaktbank): Datenverwaltungssystem zur Speicherung aller Daten- und Projektinformationen bei der Anwendung von CASE-Tools.


3.2 Architektur von SEU


Architektur einer SEU

Gemeinsame Benutzungs-Schnittstelle

CASE - Repositorium

Phasenbezogeneund Life Cycle

Werkzeuge

Front EndWerkzeuge

Back EndWerkzeuge

Schicht 3

Schicht 2

Schicht 1

Schicht 0

Kommunikations- schnittstelle

Tool-Export-Im-port-Schnittstelle

System-schnittstelle

CASE – DatenbankDateisystem Web


Schalenmodell am Beispiel Delphi

Bediensystem - Shell

Formular-Designer

Quelltext-Editor

Bild-Editor

ObjektinspektorD

aten

ban

k-A

nb

ind

er

Klassen

-

Bro

wser

Com

pile

r,Li

nkerR

apid

Pro

toty

pin

g

Debugger

Testhilfe

Hilfe-Tool

Packag

e-

Ed

itor

RepositoryProjektbibliothek

Bibliothek

Komponen

ten-

VCL


3.3 Das ECMA Referenzmodell

.. Der ECMA-Toaster


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 Reports

angenommen worden.

► Ziele:■ Zusammenarbeit mit nationalen, europäischen und internationalen

Normierungsorganisationen über die Standardisierung von Kommunikationstechnologien (ICT) und Verbraucherelektronik (CER).

■ korrekten Gebrauch von Standards anregen und kontrollieren.■ Veröfentlichung von Standards und technischer Reports, Unterstützung

ihrer Verbreitung auch in elektronischer Formu. 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/


Sichten des ECMA-Referenzmodells

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

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

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

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

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

Sicht auf Regeln beschreibt 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


ECMA-Referenzmodell

Object Management Services (Repository)

CommunikationServices

Process Management Services

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 and Configuration Services


BenutzungsschnittstelleUSER INTERFACE SERVICES

Bereitstellung einer Reihe von Diensten (services, Schnittstellen) , die zur Gewährleistung der Benutzungsschnittstellen-Integration (konsistente Bedienung) benötigt werden: User Interface Metadata Service dient der Defi nition, Steuerung und Hand-

habung von Schemata zur Unterstützung der Benutzungsschnittstelle (z. B. X-Window)

Session Service gewährleistet volle Funktion, unabhängig von Nutzer oder Hardwareumgebung (z. B. Farb- oder Monochrommonitor)

Security Service gewährleistet Sicherheitsanforderungen, wie Nutzerauthen- tifi kation, Dunkelsteuerung unbenutzbarer Funktionen u. a.

Profi le Service gestattet mögliche Veränderungen, wie z. B. Systemeinstel- lungen (Farbe), Menge zu verwendender Werkzeuge u.a.

User Interface Name and Location Service stellt fest, wer sich wo zum Sy-stem Zutritt verschafft hat. Er gewährleistet das Einloggen an allen Termi-

nals einer Multi-User-Umgebung unter gleichem Namen. Internationalization Service stellt nationale Besonderheiten (z. B. Zeichen-

sätze, Datumsformate) zum Zugriff auf das Rechnersystem bereit und gewährleistet ihre Konvertierbarkeit zwischen unterschiedlichen Ländern.


ProzessverwaltungPROCESS MANAGEMENT SERVICES

Defi nieren und organisieren die Ausführung aller Werkzeuge und Aktivitäten für den Softwareentwicklungsprozess von den rein technischen Maßnahmen bis hin zur Steuerung betriebswirtschaftlicher Aspekte: Process Defi nition Service defi niert aus den im Repository gespeicherten

Projektdaten die Bedingungen zur Ausführung neuer Aktivitäten Process Control Service steuert Prozesse im allgemeinen auf dem Niveau

eines bestimmten Vorgehensmodells zur Beeinfl ussung anderer Prozesse, wodurch der Nutzer entsprechend seiner Rolle unterstützt wird

Process Enactment Service unterstützt und bietet Möglichkeiten der Steue- rung vorher defi nierter Aktivitäten (Analyse-, Hilfe-, Simulationsfunkt.)

Process Visibility and Scoping Service legt zum Zwecke der Kommunika- tion und Koordination Sichtbarkeit, Zeitpunkt und Ort von Aktivitätsteilen für andere Aktivitäten fest

Process State Service sammelt und wertet Ereignisse von Aktivitäten wäh- rend ihrer Ausführung aus, die für die Koordination und spätere Entschei- dungsplanung anderer Projektaktivitäten notwendig sind

Process Ressource Management Service verwaltet das Festlegen von Ressourcen zur Ausführung defi nierter Prozesse für Werkzeuge und Nutzer


Werkzeuge (TOOL SERVICES)

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 (funktionale Elemente) sind auswechselbar und kommunizieren über den Communication Service oder Object Management Service mit anderen Werkzeugen und Diensten der SEU.

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 den standardisierten Vorschriften realisiert werden.


RepositoriumOBJECT MANAGEMENT SERVICES

dienen der Defi nition, der Speicherung, der Handhabung, der Verwaltung und dem Zugriff auf Objekte/Dokumente (Dateien, Programme, Bibliotheken, Projekte, Geräte usw.) und den Beziehungen zwischen ihnen: Metadata Service gestattet die Defi nition, Steuerung und Handhabung von z.B.

Schemata, um den Aufbau des Datenmodells (Daten über die Struktur von Objekten) zu unterstützen.

Data Storage and Persistence Service unterstützt das Anlegen und Speichern von Objekten nach der Metadatenbeschreibung über den Zeitraum des Pro- zesses hinaus bis zum endgültigen Löschen des Objektes.

Relationship Service erlaubt die Defi nition und Handhabung von Beziehungen (selbst wiederum eigener Typ) zwischen Objekten und Objekttypen.

Derivation Service legt Wege fest, welche Objekte von anderen abgeleitet sind (z. B. Objektcode aus Quellcode ähnlich Make-Files). Er schließt Mechanismen zur Vererbung von Datenbeschreibungen ein.

Concurrency Service sichert den gleichzeitigen zuverlässigen Zugriff für Nut- zer und Prozesse zum gleichen Objekt der Datenbasis.

Version Service unterstützt das Anlegen, Zugreifen und Verbinden von Objekt- und Konfi gurationsversionen der SEU.


Weitere Services

► POLICY ENFORCEMENT SERVICES sind für Sicherheitsaspekte, Integritätsüberwachung und Verwaltungsfunktionen zuständig:

■ Mandatory Confdentiality Service legt auf eigenen Wunsch Zugrifsrechte und Sicherheitsanforderungen (geheim, str. geheim) für Objektinfomationen fest.

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

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

► COMMUNICATION SERVICES dienen der Kommunikation zwischen Werkzeugen, zwischen Basisdiensten sowie Diensten verschiedener SEU.

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

► FRAMEWORK ADMINISTRATION AND CONFIGURATION SERVICES übernehmen die sorgfältige Installation der SEU und ihre laufende Pfege u.a.:

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

■ User Administration Service unterstützt das An- und Abmelden von Nutzern zum System


Abhängigkeiten zwischen Dienstendes ECMA - Referenzmodells

UserInterfaceMetadataService

UserAssistance

Service

PresentationService

ProfileService

ToolService

SessionService

SecurityService

User Admi-nistrationService

Internationali-zation Service

ToolRegistration

Service

MandatoryConformity

Service

MandatoryIntegrityService

MandatoryConfidentiality

Service


AD/CYCLE-Architektur

User Interface

Workstation Service

Work Management

Tool Services

AD Information Model

LibraryService

RepositoryService

ADPlatform

ADTools

Quelle: [11, S. 141]


3.4 Efektkategorien für Werkzeuge (Blutgruppen) zur Komposition in SEU

Prof. U. Aßmann, CBSE 25AS-Werkzeug

AQ-Werkzeug

AC-Werkzeug

XM-Werkzeug

RR-Werkzeug

XC-Werkzeug

RN-Werkzeug

RD-Werkzeug

XA-Werkzeug

RE-Werkzeug

RO-Werkzeug

MT-Werkzeug

MR-Werkzeug

XX-Werkzeug

AV-Werkzeug

XE-Werkzeug

Analysieren (A)‏

KonservativErweitern (X)‏

InvariantenerhaltendRestrukturieren (R)‏

Modifizieren (M)‏

Efektkategorien für Werkzeuge


Werkzeugkomposition

Wie kann man Werkzeuge einfach zu grösseren Werkzeugen komponieren?

► Realistische Werkzeuge verarbeiten immer eine DDL, DCL, DQL, DML, sowie Verhaltensspezifkationssprachen (BSL)

► Die individuelle Fertigung von solchen Werkzeugen ist zu teuer.


Idee zur Lösung

Übertrage Software-Blutgruppen-Gesetze auf Werkzeuge

► [Siedersleben, Quasar]


Software Blood Groups (Blutgruppen) (Softwarekategorien nach Wiederverwendbarkeit)

► 0: independent of application and technology■ JDK collections, C++ STL, GNU regexp

► A: application- or domain-related. Stems from domain model.

■ Client, Customer, ...► T: technology-oriented APIs, independent of

application, but not of technology■ JDBC, CORBA CosNaming

► AT: depending on application and technology■ To be avoided: hard to maintain, to reuse, to

evolve► R: for representation changes of business objects

into external representations and back■ Serialization, deserialization, encryption,

decryption, packing, unpacking■ Transporting an object from one language's

representation to anothers (e.g., Java to Cobol)

0-Software

► USES relationships:

T-Software

AT-Software

A-Software

R-Software


Architectural Components

► 0-interfaces contain only technical types (strings, collections etc)■ well reusable

► A-interfaces contain domain types (account, bill,..)■ A-components live in the Application-Logic and the Database tier■ Hard to reuse

► T-interfaces provide technical APIs■ Necessary everywhere

► R-interfaces contain both, because they change representation■ Are necessary in the middleware and data layer■ Special kind of A■ Can often be generated from specifcations, hence not reusable, but re-

generatable. XML tools, e.g., XMI (model interchange). OMG MOF tools (Model-driven development)


Zweck der Blutgruppen

► Zweck der Blutgruppen ist es, Anwendung und Technik möglichst weit voneinander zu trennen, um sie getrennt besser wiederverwenden zu können.

Siedersleben's Blutgruppen-Gesetz: Jede Schnittstelle, Klasse, und Komponentegehört genau zu einer Softwarekategorie.


Wiederverwendbarkeit der Blutgruppen

► Die Wiederverwendbarkeit der Gruppen nimmt von 0 nach AT hin ab.

■ Technisch orientierte Komponenten sind leichter wiederzuverwenden

■ Anwendungsspezifsche schwerer.

■ Problemfall AT

► Die Blutgruppen durchziehen alle Schichten der BCED-Architektur

■ Auf jeder Ebene gibt es Technik, Applikation, Repräsentation

0-Software

T-Software

AT-Software

A-Software

R-Software

--

++

+

-

--


Efektkategorie Analyse-Werkzeuge (Blutgruppe A)

► Analysewerkzeuge lesen das Repositorium, verändern aber die Artefakte nicht,

■ so dass alle bearbeiteten Artefakte unabhängig voneinander bleiben

► AS-Werkzeuge (Search, Automatisierungsgrade (1)-(3))■ Der Entwickler will also etwas über den Artefakt, seine Struktur, oder

seine Attribute wissen und setzt dazu ein AS-Werkzeug ein. ■ Bsp.: Browser (Brauser), Lister, Editoren, Suchmasken-Programme oder

Web-Browser.

AS-Werkzeug

AQ-Werkzeug

AC-WerkzeugAV-Werkzeug

Analysieren (A)‏


AQ-Werkzeuge

► AQ-Werkzeuge (Query, Automatisierungsgrad (4)).■ Diese Kategorie fragt komplexere Sachverhalte in Repositorien ab. ■ Hier berechnet man Wissen, das implizit in den Artefakten vorhanden,

aber nicht direkt ablesbar ist.

► AQ-Werkzeuge benötigen AS-Funktionalität, im Allgemeinen müssen aber weitergehende, komplexe Abfragesprachen und spezielle Abfragewerkzeuge eingesetzt werden

■ Auch die Ergebnisse sind oft so komplex strukturiert, so dass sie einer speziellen Aufbereitung bedürfen.

■ AQ-Werkzeuge sind also Query-Werkzeuge (query engines), die Wissen über Artefakte explizit darstellen.

► Beispiele: ■ logische Programmiersprachen, spezialisierte Code-Query-Werkzeuge wie

Semmle [Semmle07] bieten SQL-ähnliche Anfragesprachen an, um Codebasen zu analysieren.

■ Aufrufgraphvisualisierer, Metrikwerkzeuge und Informationssysteme für Geschäftsanalyse (business intelligence)


AC-Werkzeuge

► AC-Werkzeuge (syntactic checking, syntaktische Prüfung, Automatisierungsgrad (5)).

■ Diese Art von Werkzeugen prüft Konsistenzbedingungen über Repositorien (Integritätsregeln, integrity constraints, context conditions, validity checks).

■ Bei der Prüfung von Integritätsbedingungen muß zwischen syntaktischen und semantischen Integritätsregeln unterschieden werden.

■ Syntaktische Integritätsregeln lassen sich ohne Rückgrif auf die Semantik eines Programms überprüfen und bilden die Klasse der AC-Werkzeuge.

■ Bei der syntaktischen Prüfung wird das Ergebnis gemeldet und am Zustand des Repositoriums nichts geändert.

■ Natürlich werden zur Informationssammlung beim Prüfen AQ-Werkzeuge eingesetzt. Der Entwickler kann also mit einem AC-Werkzeug die syntaktische Konsistenz seines Artefakts prüfen.

■ Beispiele bilden z.B. ein Parser, Typprüfer oder Bedingungsprüfer (constraint checker) , Stilprüfer.


AD-Werkzeuge

► AD-Werkzeuge (diference, Diferenz- bzw. Ähnlichkeitsbestimmung) ■ Um zwei Artefakte eines Metamodells miteinander vergleichen zu

können, müssen ihre Gemeinsamkeiten und Unterschiede bestimmt werden.

■ Artefakte können bezüglich eines Gleichheitskriteriums gleich, ähnlich oder völlig verschieden sein.

■ AD-Werkzeuge werden zum Beispiel in Regressionstests eingesetzt, um Ausgabedaten verschiedener Programmversionen mit auf Übereinstimmung zu prüfen. Schlägt der Vergleich fehl, hat sich das Programm semantisch verändert, was auf einen Fehler in der Entwicklung hinweist


AV-Werkzeuge

► AV-Werkzeuge (Validation, semantic checking, semantische Prüfung. Automatisierungsgrad (6)).

■ AV-Werkzeuge prüfen die Semantik eines Programms. Zum Beispiel stellt ein Regressionstest eine semantische Prüfung dar, bei der validiert wird, ob eine neue Version die gleichen Ausgabedaten erzeugt wie eine vorhergehende.

■ Theorembeweiser wie Key beweisen, jenseits der Validierung durch Testen, die Korrektheit von Software.

■ Theorembeweiser können auch eingesetzt werden, um Verträge für Prozeduren und Methoden zu prüfen.

■ Auch können sie Anwendungen, die Frameworks benutzen, daraufhin überprüfen, ob sie das Framework korrekt benutzen.


A-Werkzeuge

► Analysewerkzeuge arbeiten idempotent, das heisst, sie können immer wieder angewendet werden, ohne dass sich ihre Ergebnisse oder auch die Artefakte sich ändern.

► Damit können Analysewerkezeuge auf einfache Weise mit Werkzeugen, die andere Efekte auf das Repositorium erzeugen, kombiniert werden.

► Insbesondere bedeutet das für die transaktionsorientierte Kopplung solcher Werkzeuge innerhalb von Softwareentwicklungsumgebungen (SEU), dass sie als Leser und nicht als Schreiber gelten, und somit parallel durchgeführt werden können.


Konservativ erweiternde Werkzeuge (X-Werkzeuge, Blutgruppe X)

► Konservativ erweiternde Werkzeuge (X-Werkzeuge) fügen den Artefakten oder dem Repositorium Informationen hinzu, zerstören aber keine Information.

► Dadurch sind sie von A-Werkzeugen unabhängig und einfach mit ihnen kombinierbar.

► X-Werkzeuge besitzen i.W. Automatisierungsgrad (4), Informationsaufbereitung, oder auch (5) Produkt-Generierung.

XM-WerkzeugXC-Werkzeug

XA-Werkzeug

XX-Werkzeug

XE-Werkzeug

KonservativErweitern (X)‏


XM-Werkzeuge

► XM-Werkzeuge (Materialisierung)■ Diese Art von Werkzeugen manifestiert Wissen, das schon implizit im

Repositorium vorhanden war, in expliziter Form. ■ Das beinhaltet AQ-Funktionalität, bedeutet aber gleichzeitig, dass das

ermittelte Wissen im Repositorium eingetragen wird.

► Somit erhöhen XM-Werkzeuge die Redundanz des Repositoriums, verbessern aber den Zugrif auf die enthaltene Information.

■ Für die Entwicklung bedeutet das, dass der Entwickler seinen Artefakt um Wissen anreichert, das implizit schon vorhanden war.

■ Dies kann nötig sein, um mit weiteren Operationen fortfahren zu können.

► Beispiele■ Erstellung von Symbol- oder Defnitionstabellen, die im Kontext

vorhandene Defnitonen von Namen zusammenfassen und zum Zugrif bereithalten.

■ Ersetzungssysteme wie Termersetzungssysteme oder Graphersetzungssysteme können eingesetzt werden


XR-Werkzeuge

► XR-Werkzeuge (Repräsentationswechsel, representation change)■ Diese Art von Werkzeugen erzeugt für einzelne Artefakte oder sogar das

ganze Repositorium eine weitere Repräsentation, ohne die existierenden Daten zu verändern.

■ Dies kann eine externe Repräsentation des Artefaktes sein, um den Artefakt zu serialisieren, zu ver- und entpacken, zu verschlüsseln oder in eine andere Sprache überführen.

► Zu XR-Werkzeugen gehören neben Transformatoren auch Generatoren, die binäre Formen von Quelldateien erzeugen, indem sie nur die Repräsentation des Quellcodes verändern, aber die Semantik erhalten.

■ Bauwerkzeuge (build tools) sind ebenfalls zu XR-Werkzeugen zu zählen, da sie den kompletten Aufbau der Systeme beschreiben und Eingabefles für die Übersetzung in eine ausführbare Form liefern


XA-Werkzeuge

► XA-Werkzeuge (Adaption, Anpassung). ■ Oft besteht der Bedarf, eine Softwareartefakt auf bestimmte

Randbedingungen anzupassen, z.B. auf die Plattform, auf der er ausgeführt werden soll, auf den Benutzer oder auf bestimmte funktionale Varianten hin.

■ Typisches Problem ist die Installation von Produkten, die sehr stark von der Umgebung des Systems abhängen und vielfältige Anpassungen erfordert.

■ Installationswerkzeuge, interaktives Adaptionswerkzeuge (Assistent, wizard).


XX-Werkzeuge

► XX-Werkzeuge (Extension, Erweiterung), Automatisierungsgrad(4)■ XX-Werkzeuge bringen in ein Repositorium eine Erweiterung ein, ohne

seinen Inhalt zu zerstören. ■ Hierunter kann man Annotationswerkzeuge für Modelle zählen oder auch

Werkzeuge, die zusätzliche Sichten auf einen Artefakt einbringen, wie zum Beispiel aspektorienterten Weber

. Trennung von Belangen (separation of concerns) in einen Kern und einen Aspekt

. Ein Weber muss eingesetzt werden, der Kern und Aspekt vereinigt.

. Für einzelne Webevorgänge kann das durchaus automatisch geschehen, für komplexere Prozesse wie z.B. die modellgetriebene Entwicklung jedoch ist das nicht unbedingt der Fall.


XE-Werkzeuge

► XE-Werkzeuge (Detaillierung, Elaboration, Automatisierungsgrad (8), (9): Entscheidungshilfe bzw. Übernahme).

■ Solche Werkzeuge werden dazu eingesetzt, um einen partiell spezifzierten Artefakt, z.B. ein Modell, zu vervollständigen. XE-Werkzeuge unterstützen dies durch die Präsentation der “Lücken” des Modells, d.h. durch die Präsentation von zu verfeinernden Teilen oder generischen Parametern.

■ Sie unterstützen also den Entwickler bei seinen Entscheidungen und sind somit Hilfswerkzeuge, die dem Entwickler bei der Vervollständigung seines Artefakts helfen.

► Bsp: ■ Elaborations-Assistenten (refnement wizards), die dem Entwickler helfen,

Parameter einzugeben, Masken, die noch fehlende Spezifkationsteile einfordern.

■ Zu dieser Kategorie zählen auch AC-Prüfwerkzeuge, die Inkonsistenzen entdecken und beim Entwickler fehlende Informationen abfragen.


X-Werkzeuge

► X-Werkzeuge verfetten die Repräsentation des Artefakts, d.h. sie führen Redundanz ein.

► Konservativ erweiternde Werkzeuge sind ebenfalls idempotent, wenn sie die bei vorhergehener Ausführung erzeugten Informationen überschreiben.

► Beispiel: ■ Back-End eines Übersetzers: besteht aus XA-Werkzeugen, die für die

Plattform, den Chip und die Laufzeitumgebung angepassten Code erzeugen, die Zwischenrepräsentation aber unangetastet lassen.


R-Werkzeuge (Blutgruppe R)

► Restrukturierende Werkzeuge verändern die Information im Repositorium, also auch die enthaltenden Artefakte.

► Allerdings vermeiden sie beliebige Änderungen, sondern erhalten bestimmte Invarianten, zum Beispiel die Semantik eines Artefakts.

■ Dadurch bleiben die Ergebnisse von anderen Werkzeugen erhalten, insofern sie auf den Invarianten Informationen aufsetzen.

► Auch diese Werkzeuge können daher oft mit A- und X-Werkzeugen auf einfache Art kombiniert werden

RR-Werkzeug

RN-Werkzeug

RD-Werkzeug

RE-Werkzeug

RO-Werkzeug

InvariantenerhaltendRestrukturieren (R)‏


RR-Werkzeuge

► RR-Werkzeuge (Refakturierung, refactoring), Automatisierungsgrad (4).

■ Refakturierung meint, die Struktur eines Artefakts oder sogar des ganzen Repositoriums zu ändern, ohne die Semantik anzutasten.

■ Für den Einsatz eines RR-Werkzeugs bedeutet dies, dass es die Semantik des Artefakts im Repositorium invariant lässt, obwohl es an seiner Struktur Veränderungen vornimmt.

► Beispiel:■ Ein RR-Werkzeug Namen von Variablen, Klassen oder Methoden

verändern; so lange es das konsistent tut, bleibt die Programmsemantik erhalten.

► In den letzten 10 Jahren haben Refakturierungswerkzeuge große Bedeutung gewonnen; mittlerweile gibt es keine Entwicklungsumgebung mehr, die keine Funktionalität für Umbenennung, Verschieben von Methoden, Aufsplitten von Klassen, etc. bietet.


RN-Werkzeuge

► RN-Werkzeuge (Normalisierung), Automatisierungsgrad (4).► Diese Art von R-Werkzeugen restrukturiert die Datenbasis, um sie in

eine Normalform zu bringen (spezielle Refakturierung). ■ Dabei kann Redundanz eingeführt oder auch eliminiert werden;

entscheidend ist, dass der Endzustand eine normalisierte Form besitzt, die für zukünftige Operationen leichter auszuwerten ist.

► Mit einer normalisierten Darstellung kann z.B. die Zahl der Fälle reduziert werden, die ein Folgewerkzeug zu untersuchen hat (vereinfachte Fallanalyse), oder es kann einfacher sein, einen Repräsentationswechsel durchzuführen.

► Normalisierungen werden häufg in einem Übersetzer oder Refakturierungswerkzeug angewandt, z.B. werden Mehrfachzuweisungen in mehrere Einfachzuweisungen umgewandelt, abkürzte Pfade entfaltet, etc.


RD-Werkzeuge

► RD-Werkzeuge (Reduktion, vertikale Transformation), Automatisierungsgrad (7).

■ Werkzeuge dieser Kategorie normalisieren in spezieller Weise, denn sie wandeln Schritt für Schritt ein Programm in einer höheren Sprache in eine Programm einer niederen Sprache.

■ Im Gegensatz zum allgemeinen Fall des Übersetzens wandelt dabei ein Reduktionsschritt genau ein Konstrukt der höheren Sprache in die niedere Sprache um (Flachklopfen, lowering). Damit werden RD-Werkzeuge oft als Präprozessoren eingesetzt.

► Beispiel:■ Codegeneratoren für domänenspezifsche Programmiersprachen (DSL).

Diese wandeln ein Programm nicht direkt in Maschinensprache, sondern in eine Hochsprache um.

■ Content-Management-Systeme: Über mehrere Stufen werden die Dokumentformate in Web- und Grafkformate umgesetzt, um sie dem Benutzer anzeigen zu können. die dazu notwendigen Schritte sind oft Reduktionen.


RE-Werkzeuge

► RE-Werkzeuge (Elimination, Entfettung, Verschlankung), Automatisierungsgrad (4).

■ RE-Werkzeuge bilden den Gegenpart zu XM-Werkzeugen. ■ Sie suchen nach redundanten Teilen der Datenbasis, die aus anderen

rekonstruiert werden können und eliminieren diese (Verschlankung).

► Beispiele ■ Entfernen von abgeleiteten Relationen■ Elimination gemeinsamer Teilausdrücke■ Ausfaktorisieren von Prozeduren oder Oberklassen.

► RE-Werkzeuge sind auf AS-Werkzeuge zurückführbar, da■ Redundanzen nur dann gefunden werden können, wenn Muster mehrfach

im Artefakt gefunden werden können (Mustersuche nach Redundanzen). ■ Zusätzlich muß dann natürlich das Replikat eliminiert werden, was einer

einfachen Transformation entspricht.


RO-Werkzeuge

► RO-Werkzeuge (Optimierung), Automatisierungsgrad (7). Optimierende Werkeuge transformieren den Artefakt bezüglich einer Optimalitätsfunktion, z. B. einer Kosten-Nutzen-Zielfunktion, die auf einem Kosten-Nutzen-Modell beruht.

► Dabei bleibt die Semantik des Programms erhalten, es ändern sich aber seine Qualitätseigenschaften, z.B. der Verbrauch an Speicher, Rechenzeit oder an Energie.


R-Werkzeuge

► R-Werkzeuge können nur dann mit A- und X-Werkzeugen kombiniert werden, wenn die Invarianten, die sie erhalten, mit dessen Funktionalität harmonieren.

► R-Werkzeuge sind kompatibel zu A- und X-Werkzeugen, falls jene auf Teilen des Repositoriums arbeiten, die nicht von der Invariante erfasst sind.


R-Werkzeuge - Beispiele

► Frontend eines Übersetzers: besteht aus RR-, XM-, und XX-Werkzeugen.

► Lexikalische Analysator:■ wandelt die Zeichen der Eingabedatei in einen Strom von Lexemen

(token), die dann vom

► Zerteiler: in einen Baum verwandelt werden, der der abstrakten Grammatik der Programmiersprache entspricht (RR).

■ Eigentlich müsste der Parser die Kontextbedingungen des Programms mitprüfen, da aber die Analyse von kontextsensitiven Grammatiken mindestens quadratischen Aufwand besitzt, spaltet man die Analyse der Namen, Typen, und Werte in eine separate AC-Phase ab (statische semantische Analyse).

■ Dabei zeigt jede Fehlermeldung der semantischen Analyse eine Verletzung der Kontextbedingungen des untersuchten Programms an, z.B. das Fehlen der Defnition einer Variablen.

► Daneben werden zur semantischen Analyse Namensrelationen in Defnitionstabellen manifestiert (XM-Werkzeug).


R-Werkzeuge - Beispiele

► Optimierer: enthält■ RE-Werkzeuge (Entfernung von gemeinsamen Teilausdrücken in

Grundblöcken), ■ normalisierende Vereinfachungen (RN-Operationen) ■ und RO-Werkzeuge (Operatorvereinfachung oder Befehlsanordnung).


Modifzierende Werkzeuge (M-Werkzeuge, Blutgruppe M)

► Modifzierende Werkzeuge ändern das Repositorium in beliebiger Art und Weise, sodass alle anderen Werkzeuge mit ihnen interagieren und alle Artefakte, die sie bearbeiten, voneinander abhängig werden.

MT-Werkzeug

MR-WerkzeugModifizieren (M)‏


MR-Werkzeuge

► MR-Werkzeuge (Reparatur, Automatisierungsgrad (4)) ■ MR-Werkzeuge ermöglichen die Beseitigung von inkonsistenten

Zuständen eines Softwareartefakts. ■ Angewandt nach AC oder AV-Werkzeugen■ Hat man mit Hilfe von Prüfwerkzeugen der Kategorie AC oder AV

Inkonsistenzen festgestellt, muß entweder durch Handprogrammierung oder mit Hilfe von geeigneten Werkzeugen Abhilfe geschafen werden.

► Als Beispiel mögen Versionsmanagementsysteme dienen, die nebenläufge, in Konfikt stehende Änderungen an einem Produkt miteinander abstimmen und beseitigen können


MT-Werkzeuge

► MT-Werkzeuge (allgemeine Transformation, Automatisierungsgrad (7): Generierung).

► MT-Werkzeuge transformierent einen zugrundeliegenden Artefakt in beliebiger Weise in eine andere Form.

► Es werden keinerlei Invarianten erhalten, sondern der Artefakt wird erweitert, restrukturiert, verändert, sodass alte und neue Version sich stark unterscheiden können.


M-Werkzeuge

► M-Werkzeuge sind am schwierigsten zu komponenieren, da sie auf dem Repositorium zwischen den Artefakten vielfältige Abhängigkeiten erzeugen.

► Beispiel: Übersetzer sollten, obwohl sie Programme transformieren, keine MT-Werkzeuge sein, da sie die Semantik des Quellprogramms im Zielprogramm wiederspiegeln müssen; sie sind daher RD-Werkzeuge.

■ Sie enthalten aber normalerweise RO-Werkzeuge, RN-Werkzeuge, und RE-Werkzeuge, sowohl im Back-End, dem Codegenerator, als auch im Middle-End, dem Optimierer.

■ Fehlerkorregierende Parser, die leichte Eingabefehler des Programmierers verbessern, entsprechen MR-Werkzeugen.


Werkzeug-Blutgruppen

► Die Efektkategorien der Werkzeuge bilden Blutgruppen für Werkzeuge [Siedersleben, Quasar]

► Die Blutgruppen drücken für verschiedene Klassen von Werkzeugen Kompatibilität bzw. Komponierbarkeit aus

■ Genauso, wie im wirklichen Leben Blutgruppen zueinander nur teilweise kompatibel sind, was sich durch eine Matrix der Kompatibilitätsrelation ausdrücken lässt, lassen sich nun Werkzeuge verschiedener Klassen anhand einer Kompatibilitätsrelation miteinander kombinieren.

Analyze eXtend Rearrange Modify

Analyze A/+ X/+ R/+ M/+-

eXtend X/+ R/+- M/+-

Rearrange R/+- M/-

Modify M/-


Softwareinfektion und Werkzeuginfektion

► Daher gilt die Regel des Softwareinfekts für Software-Blutgruppen auch für unsere Werkzeug-Efektkategorien (Werkzeug-Infekt) [Siedersleben Quasar]:

► Beispiel:■ ein A-Werkzeug, das Normalisierungen oder Reduktionen aufruft, wird

selbst zu einem RN- oder RD-Werkzeug.

► Mit den Werkzeug-Blutgruppen können auch komposite Werkzeuge in einer SEU klassifziert werden, in dem man sie auf die Kategorien der Teilwerkzeuge zurückführt.

Wenn ein Werkzeug niederer Kategorie ein Werkzeug höherer Kategorie aufruft,

wird es selbst zu einem solchen.


3.5 Objektorientierte Defnition eines Werkzeugs

Ein Werkzeug (tool) ist ein Objekt, das einen externen Zustand über Material-Objekten in

einem Repositorium verwaltet.

Siehe “Design Patterns and Frameworks”, Kapitel

“Tools and Materials”


Tools and Materials as Special Role Model

► The tool is active, has control► The material is passive and hands out data

<<use>>MaterialTool


Tool-Material Collaboration Pattern

► A tool-material collaboration (T&M role model, T&M access aspect) expresses the relation of a tool and the material

■ Characterizes a tool in the context of the material■ The material in the context of a tool■ The tool's access of the material. The tool has a view on the material,

several tools have diferent views

► More specifcally: ■ A role of the material, in collaboration with a tool

. An interface of the material, visible by a tool, for a specifc task

. An abstract class

■ Roles of a material defne the necessary operations on a material for one specifc task

. They refect usability: how can a material be used?

. Express a tool's individual needs on a material


Tools and Their Views on Material

Tool Material<<use>>

T-M Role

Tool

Material

<<use>>T-M Role

T-M Role

T-M RoleTool

MaterialClient

MaterialClient

MaterialClient


Implementing Tool-Material Roles With Interfaces

Tool MaterialView<<use>> <<inherit>>

Tool MaterialView<<use>>

<<inherit>>

View

View

► Roles can be realized by mixin inheritance or interface inheritance


Implementing Tool-Material Roles With Role Objects

Tool MaterialRole<<use>> <<has-role>>

Tool MaterialRole<<use>>

<<has-role>>

Role

Role

► Roles can be realized by role objects


Werkzeug

Material

Werkzeug

Lesbar

Schreibbar

Zusammenarbeitsschicht(collaboration layer)

Leser

Leser

Schreiber

Zusammenarbeitsschichten aus Rollen-Kollaborationen


Werkzeug

Material

Werkzeug

Zusammenarbeitsschicht

Material

Lesbar

Schreibbar

Leser

Leser

Schreiber Lesbar

Erweiterung einer Zusammenarbeitsschicht


:Werkzeug

:Material

:Werkzeug

Zusammenarbeitsschicht

:Schreiber

:Material

:Leser

:Schreibbar

:Lesbar

:Lesbar

:Leser

Implementierung mit Rollenobjekten


Schichtung der Material-Zugrifsrollen für Werkzeugobjekte (tool objects)


Werkzeug

Material

Werkzeug

Material

Leseschicht

Schreibschicht (synchronisiert)

Verteilungsschicht

Authentifikationsschicht

Werkzeug

Material

Überblick über die Schichten


Werkzeug Werkzeug

Material

Leseschicht

Schreibschicht

Verteilungsschicht


Werkzeug

Verteilungs-rolle

Authentifikations-rolle

Lese-rolle

Schreib-rolle

Material-Kern

Material mit Delegationen


Werkzeug Werkzeug

Material

Leseschicht

Schreibschicht

Verteilungsschicht


Werkzeug

Verteilungs-rolle

Authentifikations-rolle

Schreib-rolle

Material-Kern

Material-Rolle

Lese-rolle

Material als Rollenobjekt-Muster


Werkzeug-Efekte auf Materialien und Ihre Prägung für Rollen

► Erweiterungs-Rolle■ Erweitert den Zustand des Objektes, zerstört ihn aber nicht■ Atomare Erweiterung

. Erweitert den Zustand der atomaren Attribute des Objektes

■ Strukturelle Erweiterung. Erweitert die strukturellen Attribute des Objektes, d.h. Des Objektnetzes, ohne

die atomaren Attribute zu modifzieren

► Modifkation■ Atomare Modifkation

. Ändert den Zustand der atomaren Attribute des Objektes

■ Strukturelle Modifkation. Ändert den Zustand des Objektnetzes, ohne die atomaren Attribute zu

modifzieren

► Allgemeine Modifkation■ Alle obigen Efekte.


AllgemeineSchreibschicht

WerkzeugWerkzeug

Material

Leseschicht

Schicht strukturelles Schreiben

Werkzeug

Erweiterungsrolle

AtormareSchreibrolle

Schreib-rolle

Material-Kern

Material-Rolle

Strukturelle Schreibrolle

Leserolle

Schicht atomares Schreiben

Efekte auf Materialien und Ihre Prägung für Rollen

Schicht atomares Erweitern

Schicht strukturelles Erweitern


Leser-Schreiber-Kompositionsgesetze für Werkzeuge

► Folgende Werkzeugobjekte (tool objects) können komponiert werden:

■ Atomare und strukturelle Schreiber sind voneinander unabhängig■ Leser sind untereinander unabhängig■ Struktur-Leser und Atomare-Schreiber sind unabhängig■ Erweiterungs-Werkzeuge

Tool

Material

<<extend>> <<extend>>T-M Role

<<structural write>>T-M Role

<<read>>T-M Role

Tool

MaterialClient

MaterialClient

<<read>>

<<structural write>>

<<structural write>>


3.6 Der Graph-Logik-Isomorphismus

Ein typisierter Multigraph ist äquivalent zu einer Logik-Faktenbasis erster Ordnung. [COU90]


► Ein Artefakt kann■ als Graph mit typisierten Knoten und Kanten im Repositorium

gespeichert werden (Schema: Relationale Algebra, ERD, UML-CD)■ als Faktenbasis für eine Logikmaschine verwendet werden ■ Umwandlung möglich


Graphersetzungs-werkzeuge

Termersetzungs-werkzeuge

Logik-werkzeuge

Interpretation als Fakten

Spezial-Werkzeuge

GraphenIm Repositorium

Persistente Graphen

Architektur


Nutzung beim Bau von A-Werkzeugen

► Queries:■ Relationale Anfragesprachen verwendbar (siehe Semmle, SPARQL, oder

SQL)■ Datalog verwendbar■ Kantenadditionssysteme (EARS) verwendbar (s. ST-II)

► Beispiele:■ Analysierende Übersetzerphasen, wie die semantische Analyse oder die

Programmanalyse. . Insbesondere bilden Konsistenzregeln und Kontextbedingungen der

semantischen Analyse Integritätsbedingungen auf dem Programm. . Reengineering-Werkzeuge können mit Logik Informationen aus Altsystemen

ziehen

■ Klassengraphen können als Faktenbasis einer Logikmaschine behandelt werden

. Entwurfsmuster können als Logikregeln ausgedrückt werden

■ Konfgurationsmanagement kann als Deduktion über Konfgurationsgraphen ausgedrückt werden


Bau von XM-Werkzeugen mit Logik

► Um Erweiterungen von Graphen zu berechnen und zu materialisieren, kann ebenfalls Logik verwendet werden.

► Da Logik ohne Seitenefekte auf die Datenbasis arbeitet, muss Information, die berechnet werden soll, mitgeschleift werden

■ Die Graphen, die materialisiert werden sollen, müssen, als Parameter durch Anfragen durchgeschleift und durch Suchergebnisse sukzessive erweitert werden,

■ während die Datenbasis unangetastet bleibt.

► Danach kann man die Ergebnisse der Anfrage materialisieren, d.h., der Faktenbasis zugeben.

► Das bedeutet, dass ein logikbasiertes X-Werkzeug, das einen Artefakt erweitern will, zunächst Graphen zunächst als Parameter von logischen Queries berechnen muss, und dann erst materialisieren kann.


Bau von RM und RC-Werkzeugen

► können mit Logik spezifziert werden. ► Beispiel:

■ Generatoren, die ein Repositorium serialisieren, können durch Logik beschrieben werden.


Bau von M-Werkzeugen mit Logik: Schwierig

► Die Erstellung von weitergehende Transformationen ist mit Logik -- wegen ihrer Dekarativität - nur durch Wechsel des Repositoriums möglich,

■ wenn während der Abarbeitung daser gesamte transformierte Graph Repositoriums als Parameter der Query berechnet wird und man das Repositorium nach der Query komplett auf das Resultat umsetzt.

► Teuer: Da diese Operation relativ viel Speicher kostet, jedenfalls mehr als eine Veränderung des Repositoriums, wird in diesen Fällen Logik selten eingesetzt.

► Zur echten Transformation eines Artefakts können eingesetzt werden:

■ Metaprogramme■ Ersetzungssysteme.

. Termersetzungssysteme

. Graphersetzungssysteme


Metaprogramme

► Metaprogramme sind Programme, die Programme erzeugen oder Transformieren.

■ Sie haben seit Lisp eine lange Tradition

► Statische Metaprogramme produzieren ein Programm, in dem sie selbst nicht enthalten sind.

■ Sie funktionieren also als reiner Generator.

► Dynamische Metaprogramme laufen ständig mit der Anwendung mit und regenerieren Teile neu.

■ Dynamische Metaprogramme sind allerdings laufzeitintensiv und verhindern eine statische Analyse der dynamisch produzierten Programme.


Termersetzungssysteme

► Termersetzungssysteme setzen voraus, dass baumartige Datenstrukturen vorliegen und operieren daher meist auf dem abstrakten Syntaxbaum (AST).

► Einsatz:■ Identifkation von Baummustern, ■ Verschlankungen■ oder Normalisierungen.

► Strategien:■ Freies Ersetzen (chaotic rewriting): alle Regeln solange angewendet

werden, bis das Repositorium sich nicht mehr ändert■ Spezialstrategien: Die Spezifkation von Strategien möglich, die die

Regeln in bestimmter Reihenfolge auf das Repositorium anwenden . Beispiel: Das alternierende Suchen und Löschen von gefundenen

Informationen.

■ Strategien sind also Regeln zweiter Ordnung, die Regelanwendungen steuern können


Graphersetzungssysteme

► Graphersetzungssysteme unterliegen der Einschränkung auf Baumdaten nicht.

■ Sie suchen und ersetzen Graphmuster in Graphen.

► Beispiel: Softwareentwicklungsumgebung (PROGRES)■ Reduziert vielfältige Aufgaben im Entwicklungsprozess auf

Graphersetzung (und Logik) ■ Übersetzung [Nagl]■ Verfeinerung im Entwurf [Schürr, Lewerentz]■ Konfgurationsmanagement [Westfechtel].

► Das Nachfolge-Werkzeug FUJABA www.fujaba.de setzt diese Entwicklung fort

■ Findet direkte Anwendung in der modellgetriebenen Entwicklung.

http://www.fujaba.de/


Konsequenz des Graph-Logik-Isomorphismus

► Wegen des Graph-Logik-Isomorphismus ist ein nahtloser Übergang zu Werkzeugen möglich, die mit Logik spezifziert sind.

► Daher können in einer SEU logikbasierte Werkzeuge mit ersetzungsbasierten Werkzeugen eng zusammenarbeiten:

■ die unterliegenden Graphen der Artefakte können je nach Bedarf als Fakten oder Graphen interpretiert werden.


Ausblick

► Der Einsatz von Logik, Graphersetzungssystemen und Termersetzungswerkzeugen in Entwicklungsumgebungen ist noch kein Standard.

► Es ist aber vorauszusehen, dass diese generischen Werkzeuge wesentliche Bestandteile liefern werden,

■ sobald sie schnell und robust genug geworden sind ■ die Ausbildung die Konzepte in genügender Tiefe und Breite gelehrt hat.

► Viele der im Folgenden vorgestellten Werkzeuge können vereinheitlicht werden, indem Logik- und Ersetzungsspezifkationen Werkzeugt beschreiben und zu ihrer Generierung eingesetzt werden

► Damit könnten Werkzeugkomponenten und -rahmenwerke entstehen,

■ Die die Kosten für den Softwarewerkzeugbau senken■ In einer SEU wären Logikmaschinen und Ersetzungssysteme

Standardwerkzeuge

3. Architektur von Software-...

Documents

Transcript of 3. Architektur von Software-...