Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Transkript

1 Diplomarbeit Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle von Patrick Dohrmann Matrikelnr.: Mai 2009 Eingereicht bei: Technische Universität Clausthal Institut für Informatik Abteilung Software Systems Engineering Julius-Albert-Straße Clausthal-Zellerfeld Erstprüfer: Zweitprüfer: Betreuer: Prof. Dr. A. Rausch Prof. Dr. J. Müller Dipl. Inform. S. Herold

2

3 Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Stellen der Arbeit, die wörtlich oder sinngemäß übernommen worden sind, sind kenntlich gemacht. Weiterhin versichere ich, dass diese Arbeit keiner Prüfungsbehörde in gleicher oder ähnlicher Form vorgelegt worden ist. Goslar, den 27. Mai 2009 Patrick Dohrmann

4

5 Zusammenfassung In der modellgetriebenen Softwareentwicklung ist die Unified Modeling Language die zentrale Sprache, um Softwarearchitekturen und ihre Designs zu modellieren. Bei dem Entwicklungsprozess einer neuen Software können beim Übergang von einem Architekturmodell zu einem Designmodell Inkonsistenzen zwischen den Anforderungen und Eigenschaften beider Modelle entstehen oder unerwünschte Eigenschaften im Designmodell auftreten, die durch die Systemanforderungen nicht erlaubt sind. Im Rahmen der vorliegenden Arbeit ist ein Werkzeug konzeptioniert und entwickelt worden, um Modelle auf bestimmte Eigenschaften und strukturelle Anforderungen automatisch überprüfen zu lassen, um solche Inkonsistenzen zwischen Architektur und Design sowie auch andere Eigenschaften zu detektieren. Es baut auf der Benutzung des Logikprogramms TyRuBa als Anfragemechanismus auf, weshalb eine Transformation des UML-Modells in Fakten der Logiksprache nötig ist. Das Werkzeug wird durch eine Anwendung auf ein Beispielmodell evaluiert, in dem dies auf eine Einhaltung einer strikten Schichtenarchitektur überprüft wird. i

6 ii

7 Inhaltsverzeichnis 1 Einleitung und Motivation Ausgangssituation Ziele Gliederung Grundlagen Modelle Eclipse Modeling Framework Architekturmuster Logikprogrammierung Allgemein TyRuBa Common Component Modeling Example Motivation von CoCoME Das Modellierungsbeispiel Architektur und Design von CoCoME Architektur Design Ansatz Konzeption der Modelltransformation Konzeption von Prädikaten für UML-Elemente Generierung von Prädikaten Generierung der Fakten Konzeption von Regeln Überblick Darstellung der Schichten Entwicklung einer Schichtenregel Zusammenfassung iii

8 Inhaltsverzeichnis 5 Design und Implementierung Designüberblick Teilsystem Metamodel to Logic Transformation Design Implementierung Teilsystem Model to Logic Transformation Design Implementierung Teilsystem Benutzerschnittstelle Grundlagen eines Eclipse Plugins Design Teilsystem Anfrageausführung Design Exemplarischer Ablauf Zusammenfassung Anwendung Überprüfung von CoCoME Erweiterung von CoCoME auf dem Designmodell Erweiterung von CoCoME durch eine neue Architektur Zusammenfassung Verwandte Arbeiten Logikbasierte Ansätze OCL- und Datenbank-basierte Ansätze Zusammenfassung Ergebnisse und Ausblick Ergebnisse Ausblick Literaturverzeichnis 107 iv

9 1 Einleitung und Motivation 1.1 Ausgangssituation In der modellgeriebenen Softwareentwicklung sind Modelle, wie sie sich beispielsweise mit der Unified Modeling Language (UML) modellieren lassen, die zentralen Artefakte des Entwicklers. Modelle beschreiben abstrakt, aus welchen Komponenten und Bausteinen ein Softwaresystem besteht, in welchem Verhältnis diese stehen und wie sie sich verhalten. Ein Softwareentwickler, der zu einem abstrakten Modell, einem Architekturmodell, ein konkretes Modell, ein Designmodell, entwirft, kann bei der Modellierung wichtige strukturelle Eigenschaften, die das Architekturmodell fordert, verletzen, so dass beide Modelle nicht mehr konform zueinander sind. Der Grund hierfür liegt in den verschiedenen Abstraktionsebenen der Modelle, die in Beziehung zueinander stehen, diese Beziehung aber nicht formal ausgedrückt wird. In der modellgetriebenen Softwareentwicklung wird ein System vorerst mit einem Grobdesign modelliert, welches sich durch Modelltransformationen immer weiter verfeinert wird. Entsteht in einer dieser Iterationen ein Fehler, so pflanzt er sich durch alle folgenden Verfeinerungsschritte fort und es können durch ihn ursprüngliche Forderungen, die ein Modell ausgedrückt hat, durch ein verfeinertes Modell nicht mehr erfüllt sein. Der Entwickler sollte daher zur Unterstützung der Modellierung eine Möglichkeit haben, Eigenschaften von Modellen oder ihre strukturellen Forderungen überprüfen zu können. Hierfür ist es notwendig, Anfragen an ein Modell formal zu formulieren, um eine automatische Überprüfung auf bestimmte Eigenschaften eines Modells zu ermöglichen und Fehlerquellen auszuschließen. Es gibt verschiedene Möglichkeiten, ein Formalismus zu beschreiben und Anfragen zu stellen. Beispielsweise kann ein Modell in einer relationalen Datenbank gespeichert werden und Datenbank-Anfragen an das Modell formuliert werden. Eine weitere Möglichkeit bietet eine Anfrage an das Modell über die Object Constraint Language (OCL), um bestimmte Eigenschaften zu überprüfen. In dieser Arbeit wird jedoch die Verwendung einer Logikprogrammiersprache als ein Formalismus und Anfragemechanismus konzipiert, entwickelt und anhand eines Beispielmodells evaluiert. 1

10 1 Einleitung und Motivation Eine Logikprogrammiersprache ermöglicht es, auf eine geeignete Repräsentation des Modells als Wissensbasis, formale Anfragen formulieren zu lassen, die eine Überprüfung auf bestimmte Eigenschaften zulässt. Hierfür müssen alle Informationen, die in einem Modell stecken, als Fakten interpretiert in die Wissensbasis der Logikprogrammiersprache übersetzt werden. Ebenso müssen Regeln und Fakten aus einem Architekturmodell generiert werden, die die Eigenschaften der Architektur repräsentieren. Die Abbildung 1.1 zeigt schematisch das Vorgehen einer Konsistenzprüfung zwischen einem Architekturmodell und einem Designmodell. Abbildung 1.1: Zwei unterschiedliche Modelle müssen auf eine Konsistenz überprüft werden Es müssen aus dem Architekturmodell und aus dem Designmodell Fakten und Regeln gewonnen werden, die jeweils die Modelle repräsentieren und in die Wissensbasis der Logikprogrammiersprache geschrieben werden. Weiterhin zeigt die Abbildung eine Transformation des Architekturmodells in Anfragen. Diese müssen aus der Semantik, die die Architektur definiert, generiert werden und können auf der gemeinsamen Wissensbasis beider Modelle angefragt werden. 2

11 1.2 Ziele 1.2 Ziele Das Ziel dieser Diplomarbeit ist es, ein Werkzeug zu konzipieren und zu realisieren, das ein UML-Modell als Fakten einer Wissensbasis interpretiert und Anfragen auf diese Fakten gestattet. Es wird hierbei ein Augenmerk auf die Klassendiagramme der UML gelegt und als Anwendungsbeispiel ein Designmodell angenommen, das auf eine strikte Schichtenarchitektur überprüft werden soll. Die Generierung von Regeln und Fakten aus einer Architektur ist nicht Gegenstand dieser Arbeit, weshalb diese Regeln konzipiert werden müssen, um eine Überprüfung auf die strikte Schichtenarchitektur zu ermöglichen. Die Verwendung einer Logikprogrammiersprache erweist sich als Anfrage- und Überprüfwerkzeug als nützlich, da prädikatenlogische Formeln intuitiv in Notation der Logikprogrammiersprache notiert werden können. Für die Generierung von Fakten müssen sich Gedanken darüber gemacht werden, welche Fakten für ein gegebenes Modell relevant sind, welche Prädikate wichtig sind, um Beziehungen zwischen Modellelementen darzustellen, und wie sich Regeln definieren lassen, um strukturelle Eigenschaften von Modellen zu überprüfen. Dabei soll die Generierung möglichst abstrakt gehalten werden, damit das Werkzeug auch für andere Metamodelle nutzbar und somit sein Einsatzgebiet erweitert wird. Das konzipierte Werkzeug wird anhand eines realistischen Beispiels und Erweiterungen dieses Beispiels evaluiert. 1.3 Gliederung Diese Arbeit gliedert sich in sieben Kapitel. Nach der Einleitung im ersten Kapitel, schafft das zweite die Grundlagen zu wichtigen Konzepten und Begriffen der modellgetriebenen Softwareentwicklung, wie der Meta Object Facility, dem UML- Metamodell und dem Modell. Das Kapitel erläutert die verschiedenen Abstraktionsebenen. Zudem wird an dieser Stelle auf das Eclipse Modeling Framework eingegangen, weil es essentiell für das Werkzeug ist. Das Framework stellt ein UML-Metamodell zur Verfügung, das die Grundlage für die Modellierung und die Modelltransformation bietet. Das Kapitel beschreibt weiterhin, was ein Architekturmuster ist. Es gibt in der UML zahlreiche Verhaltens- und Strukturdiagramme, doch bieten sie nicht die Möglichkeit direkt eine Architektur zu modellieren. 3

12 1 Einleitung und Motivation Des Weiteren wird in Kapitel zwei die Methodik und Funktionsweise von Logikprogrammiersprachen erläutert. Hierbei wird speziell auf das Programm TyRuBa (Type Rule Based) eingegangen, das als Anfrageprogramm im realisierten Werkzeug zum Tragen kommt. Das dritte Kapitel führt das Beispielsystem CoCoME (Common Component Modeling Example) [CoCoME] ein, das immer wieder als Beispiel für das realisierte Werkzeug dieser Arbeit verwendet wird. Es handelt sich hierbei um einen Ansatz, ein allgemeines Beispielsystem als komponentenbasiertes System zu modellieren. Dabei soll hier speziell auf das Design und die Architektur des Modells eingegangen werden, welches durch das Werkzeug auf bestimmte Eigenschaften hin überprüft werden soll. In Kapitel vier ist die Konzeption des Werkzeugs beschrieben, das eine automatische Überprüfung auf UML-Modellen ermöglicht. Es ist in zwei Unterkapitel unterteilt. Im ersten wird Schritt für Schritt die Konzeption erläutert, aus einem Modell Fakten für eine Wissensbasis zu generieren. Es müssen hier wie oben bereits erwähnt die Fragen geklärt werden, welche Prädikate nötig sind um UML- Modelle als logische Wissensbasis darzustellen. Das Meta-Metamodell sowie das UML-Metamodell bereiten hier die Grundlage, auf einer abstrakten Ebene für die Ermittlung und Generierung solcher Prädikate zu bleiben. Das zweite Unterkapitel befasst sich auf die Konzeption von Regeln, die TyRuBa eine Überprüfung auf bestimmte Eigenschaften, wie eine strikte Schichtenarchitektur, erlauben. Das fünfte Kapitel beschreibt die Realisierung des Ansatzes als ein Eclipse-Plugin. Es wird erklärt, wie die Konzepte aus dem vorangegangen Kapitel in das Design dieses Systems einfließen und wie sie als Programmcode umgesetzt werden. Des Weiteren wird gezeigt, wie das Werkzeug eine Anfrage annimmt, verarbeitet und ausgibt. Das sechste Kapitel beschreibt die Anwendung des Werkzeugs auf das in Kapitel drei vorgestellte Beispielsystem CoCoME. Es behandelt eine Überprüfung des zum System korrespondierenden UML-Modells mit einer Anfrageformulierung, einer Auswertung des Ergebnisses einer Anfrage und einer Fehlerkorrektur, für den Fall, dass eine Überprüfung ein Ergebnis liefert, das eine bestimmte Anforderung an das Modell verletzt. Weiterhin werden zwei Erweiterungen des CoCoME-Beispiels diskutiert, bei denen es sich um Änderungen der Systemanforderungen handelt. Die erste Erweiterung geschieht auf Designebene, indem das Modell durch neue Modellelemente erweitert wird. Bei der zweiten Erweiterung ändert sich die zugrunde liegende Architektur 4

13 1.3 Gliederung des Modells, so dass auch das Design angepasst werden muss. Beide Erweiterungen werden wiederum mit dem entwickelten Werkzeug auf bestimmte Anforderungen und Eigenschaften überprüft und detektierte Fehler, die durch die Modellierung entstanden sind, diskutiert. Das siebte Kapitel beschreibt verwandte Arbeiten, die mit verschiedenen Methoden Anfragen auf Modelle formulieren. Der Ansatz dieser Arbeit ist einer von vielen anderen, welche jeweils unterschiedliche Anfragesprachen benutzen und unterschiedliche Probleme lösen. Daher soll hier ein Blick auf diese anderen Methodiken geworfen werden. Das achte Kapitel fasst die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf weitere Einsatzmöglichkeiten und Arbeiten, die das entwickelte Werkzeug dieser Arbeit verbessern und erwitern können. 5

14 1 Einleitung und Motivation 6

15 2 Grundlagen Bevor die Konzeption des Werkzeugs beschrieben wird, sollen an dieser Stelle wichtige Begriffe erörtert werden, die in dieser Arbeit immer wieder aufgegriffen werden. Der erste Teil dieses Kapitels geht auf die Grundlagen der Modellierung ein und erklärt die abstrakte Idee eines Modells und eines Metamodells. Hier wird speziell ein Blick auf die Unified Modeling Language (UML) geworfen. Als Unterstützung der Modellierung wird im zweiten Abschnitt auf das Eclipse Modeling Framework eingegangen, mit dem sich Modelle der UML erstellen und manipulieren lassen. Der dritte Abschnitt erläutert das Schichten-Architekturmuster. Das Beispielmodell, auf das das entwickelte Werkzeug dieser Arbeit angewendet werden soll, weist eine solche Architektur auf, wie im dritten Kapitel gezeigt wird. Der vierte Teil des Kapitels fokussiert auf die Grundlagen von Logikprogrammiersprachen und erläutert das Programm TyRuBa. 2.1 Modelle Modelle sind Artefakte, die die Realität abstrakt abbilden, um bestimmte Eigenschaften hervorzuheben. Sie können anhand verschiedener Aspekte unterschieden werden. Es gibt beispielsweise textuelle und grafische Modelle sowie auch menschen- und maschinenlesbare Modelle. Softwareentwickler nutzen in der modellgetriebenen Softwareentwicklung Modelle, die auf der Unified Modeling Language beruhen, mit denen sich Softwaresysteme modellieren lassen. Hier spielt der Formalisierungsgrad von Modellen eine wichtige Rolle. Ein Modell gilt als formal, wenn seine definierende Sprache formal ist. Die Object Management Group (OMG) drückt dies wie folgt aus: A specification is said to be formal when it is based on a language that has a well-defined form [syntax], meaning [semantics], and possibly rules of analysis, inference, or proof for its constructs. [MiMu01]. Ein Formalismus ist ähnlich zu einem Kalkül ein mathematisch exaktes, widerspruchsfreies und 7

16 2 Grundlagen vollständiges Regelwerk. Eine modellbeschreibende Sprache wird Metamodell genannt, die alle Elemente eines Modells, eine Syntax und eine Semantik definiert. Das UML-Metamodell ist für Softwareentwickler eine einheitliche Modellierungssprache für Softwaresysteme, Geschäftsprozesse und weitere Aspekte von Systemen, mit festgelegter Syntax und Notation. Es definiert Begriffe aus dem Bereich der Modellierung und stellt Beschreibungstechniken bereit, um diese Begriffe in eine Beziehung zueinander zu setzen. Die UML ist nach der International Standardization Orgranisation (ISO) standardisiert (ISO/IEC 19501). Sie legt als modellbeschreibende Sprache eine abstrakte und konkrete Syntax sowie auch eine Semantik fest. Die abstrakte Syntax beschreibt, wie die Begriffe aus der Modellierung zu einem Modell konstruiert werden können, während die konkrete Syntax die Darstellung und Notationsweise dieser Konstrukte beschreibt. Das UML-Metamodell besteht aus drei logischen Teilen: Infrastructure: Sie beinhaltet die Kernelemente der Sprache, die durch die Superstructure weiter spezialisiert werden. Superstructure: Sie beinhaltet die Elemente, mit denen der Benutzer während der Modellierung in Kontakt kommt. Profiles: Sie dienen dem Benutzer zur Anpassung des UML-Metamodells an eine Domäne, für die er modelliert. Die Infrastructure besteht aus den Paketen Core und Profiles, wie Abbildung 2.1 zeigt. Das Core-Paket unterteilt sich wiederum in vier Pakete: Primitive Types: Dieses Paket beinhaltet elementare Datentypen des Metamodells wie Boolean, Integer, String und UnlimitedNatural. Basic: Das Basic-Paket definiert eine Art Grundmetamodell und definiert Modellelemente wie Class, Property, Operation, Package, Generalisation, aber keine Association. Abstractions: Dieses Paket beinhaltet eine Menge von Eigenschaftsklassen und -paketen. Constructs: Das Constructs-Paket definiert den eigentlichen Kern der UML und erweitert das Grundmetamodell. 8

17 2.1 Modelle Abbildung 2.1: Die Pakete der Infrastructure Die Superstructure des UML-Metamodells teilt sich in zwei Kategorien der Modellierung auf. Die erste ist die Modellierung von Strukturmodellen, die beispielweise die Komposition von Klassen zeigen, und die zweite beschreibt die Modellierung von Verhaltensmodellen, die Abläufe und das Verhalten des Modells zeigen. Abbildung 2.2 zeigt die Pakete der UML-Superstructure und ihre Unterteilung. Zu den Strukturmodellen gehören Komponentenstruktur-, Klassen- oder auch Deploymentdiagramme und zur Kategorie der Verhaltensmodelle Use-Case-, Sequenzoder auch Aktivitätsdiagramm. Insgesamt definiert die UML 13 verschiedene Diagrammarten. Das UML-Metamodell hat ebenfalls ein Metamodell, durch das es beschrieben wird. Es wird Meta Object Facility (MOF) [OMGM06] genannt und definiert neben dem UML-Metamodell weitere Metamodelle, wie beispielsweise das Common Warehouse Metamodell (CWM). Der Kern der MOF setzt sich aus zwei Teilen zusammen. Der erste Teil ist die Essential MOF (EMOF), die ein Meta-Metamodell definiert, das die Essenz der MOF und damit ein einfaches Metamodell darstellt. Es erleichtert zum einen die Lesbarkeit und zum anderen dem Modellierer die Modellierung eines eigenen Metamodells. Der zweite Teil ist die Complete MOF (CMOF), welche die EMOF erweitert und das Metamodell der UML-Superstructure bildet. Es ist wichtig zu erwähnen, dass die MOF auf Konzepte der UML-Infrastructure zugreift und diese spezialisiert. Da aber ein Modell immer eine Instanz seines übergeordneten Metamodells ist, speziell also die UML-Infrastructure (ein Teil der UML) eine Instanz des MOF-Kerns ist, 9

18 2 Grundlagen Abbildung 2.2: Die Pakete der Superstructure aber das Metamodell Konzepte des darunter liegenden Modells spezialisiert, führt dies zu dem bekannten Henne-Ei Problem. Abbildung 2.3 zeigt die Abhängigkeiten zwischen der Meta-Metamodellebene und der darunter liegenden Metamodellebene. 2.2 Eclipse Modeling Framework Das Eclipse Modeling Framework, kurz EMF, ist ein Open-Source-Projekt, das eine Programmierschnittstelle für die Manipulation von Modellen bereitstellt. Modelle im EMF werden durch XMI (XML Metadata Interchange) [OMGX07], welche durch die OMG spezifiziert ist, um die Austauschbarkeit von Modellen zu garantieren, und durch die EMF-API als Objektstrukturen repräsentiert. Diese Modellelement-Objekte können auf Programmierebene bearbeitet werden, indem beispielsweise Werte von Attributen verändert oder ausgelesen werden. Für diese Arbeit spielt der Umgang mit der API eine wichtige Rolle, da sie auf der Programmierebene den Zugang zu einem Modell und seinen Elementen bietet. 10

19 2.3 Architekturmuster Abbildung 2.3: Abhängigkeiten zwischen Meta-Metamodellebene und Metmodellebene Eine weitere Anwendung erschließt sich durch die Modellierung von Metamodellen, die es gestatten, in Eclipse einen Editor zu generieren, mit dem sich Modelle des definierten Metamodells modellieren lassen. Das EMF enthält eine Implementierung der EMOF, die UML.ecore-Datei, welche das UML-Metamodell definiert. Diese Metamodell-Datei spielt bei dem Transformationsprozess eines UML-Modells in Fakten einer Wissensbasis eine tragende Rolle, wie es in Kapitel 4 erläutert wird. 2.3 Architekturmuster Wenn ein Softwarearchitekt bei seiner Arbeit mit einem neuen Problem konfrontiert wird, so wird er nicht versuchen, mühsam eine neue Lösung zu finden, sondern versuchen, eine bereits existierende Lösung für ein ähnliches Problem zu benutzen, indem die Grundaspekte der Lösung wiederverwendet werden. Der Entwickler greift hier also auf bestehende Muster (Patterns) zurück, die spezielle Probleme abstrahieren. Ein Muster lässt sich wie folgt definieren: Each pattern is a threepart rule, which expresses a relation between a certain context, a problem, and a solution [Alex79]. Muster sind in der Lage, Objekte zu beschreiben sowie Be- 11

20 2 Grundlagen ziehungen unter diesen in den Vordergrund zu stellen. Sie können aufgrund ihrer Abstraktion von Problemlösungen wiederverwendet und als Hilfsmittel eingesetzt werden, um unter anderem Softwarearchitekturen zu beschreiben. Muster werden in drei Kategorien unterschieden: Architekturmuster: Softwarearchitekturen unterliegen bestimmten allgemeinen Strukturprinzipien, die ein System geeignet beschreiben. Diese Strukturen werden als Architekturmuster bezeichnet. Architectural patterns are templates for concrete software architectures. They specify the system-wide structural properties of an appplication. [FBus96]. Ein Beispiel für ein Architekturmuster ist der Model-View-Controller bei dem es darum geht, eine Benutzerschnittstelle für ein System so zu entwerfen, dass sie austauschbar bleibt. Das System wird daher in die Komponenten Model, welches die Daten des Systems hält, View, welcher die Systemdaten anzeigt, und Controller, welcher auf Benutzereingaben reagiert, dekomponiert. Es ist somit möglich, dass mehrere unterschiedliche Views auf die Daten und unterschiedliche Benuzterschnittstellen an das System gebunden werden können. Designmuster: Eine Softwarearchitektur lässt sich meist als eine Menge kleinerer Subsysteme beschreiben. Designmuster werden auf solche Subsysteme angewendet, um es oder seine Beziehungen zu anderen Subsystemen zu verfeinern. Ein Beispiel für ein Designmuster ist das Iterator-Muster. Es wird verwendet, wenn auf Elementen, die aggregiert sind, sequentiell zugegriffen werden soll, ohne dass dabei die Aggregation angefasst werden muss [GHJV95] S. 257ff. Idioms: Ein Idiom ist ein Muster auf niedriger Abstraktionsebene, das beschreibt, wie bestimmte Aspekte von Komponenten und ihren Beziehungen untereinander in einer Programmiersprache implementiert werden. Diese Arbeit wird ihr Hauptaugenmerk auf das Schichten-Architekturmuster legen [FBus96]. Bei einer Schichtenarchitektur wird ein System so strukturiert, dass bestimmte Funktionen und Aspekte des Systems, die eine gemeinsame Aufgabe erfüllen, gruppiert werden. Es entsteht unter den Schichten dabei eine geringe Kopplung untereinander. Das hat den Vorteil, dass eine Quellcodeveränderung sich nur innerhalb einer Schicht fortpflanzt und nicht das komplette System angepasst werden muss. Außerdem gibt es die Möglichkeit, Schichten durch andere zu ersetzen, sofern sie für die Kommunikation unter den anderen Schichten dieselben Schnittstellen bereitstellen. Schichten können von anderen Schichten abhängen, indem sie beispielsweise Funktionen oder Dienste durch angebotene Schnittstellen dieser wahrnehmen. Ergibt sich auf den Schichten eine vollständige Ordnung, bei der 12

21 2.4 Logikprogrammierung jeweils eine Schicht von einer Nachfolgerschicht abhängt, so wird diese Schichtenarchitektur als strikt bezeichnet. Ein typisches Informationssystem, wie in Abbildung 2.4, kann beispielsweise in drei Schichten dekomponiert werden, wobei jede Schicht entkoppelt von einer anderen bestimmte Funktionen des Systems kapselt. Die Schichten lauten Datenhaltungsschicht, Applikationsschicht und Präsentationsschicht und sie haben folgende Aufgaben [TaSt08]: Datenhaltungsschicht: Sie hält Daten persistent im Speicher und kann neue Datensätze anlegen oder löschen. Sie stellt der Applikationsschicht eine Schnittstelle zur Verfügung, die Daten in einer bestimmten Form weiterreicht, um auf ihnen Funktionen, wie das Anlegen, Löschen oder Manipulieren, auszuführen. Applikationsschicht: Diese Schicht bildet die Applikationslogik und lässt sich in drei Teilkomponenten unterteilen. Die erste Komponente bietet der Präsentationsschicht eine Schnittstelle an, damit das System geeignet auf Benutzereingaben reagieren kann. Die zweite Komponente arbeitet eng mit der Datenhaltungsschicht zusammen, damit neue Datensätze angelegt, gelöscht oder manipuliert werden können. Die dritte Komponente enthält die Kernfunktionen des Systems und legt damit das Systemverhalten fest. Präsentationsschicht: Diese Schicht verwaltet die Darstellung von (berechneten) Daten des Systems, beispielsweise auf einem Bildschirm. Es bietet dem Benutzer des Systems eine geeignete Schnittstelle an, mit der der Benutzer mit dem System interagieren kann. Diese Drei-Schichten-Architektur ist strikt, da eine Schicht jeweils nur die Schnittstellen einer benachbarten Schicht benutzt und sie selber ihre Schnittstellen nur einer anderen bereitstellt. Eine Schichtenarchitektur muss allerdings nicht immer strikt sein. Es ist denkbar, dass jede Schicht auf eine Unterstützungsschicht zugreifen kann, die beispielsweise ein Tracing oder Loging vornimmt. 2.4 Logikprogrammierung Dieser Abschnitt befasst sich mit den allgemeinen Grundlagen einer Logikprogrammiersprache und stellt die Sprache TyRuBa vor. 13

22 2 Grundlagen Abbildung 2.4: Ein allgemeines Informationssystem mit drei Schichten Der erste Unterabschnitt erläutert Grundlegendes zu Logikprogrammiersprachen, wo sie Anwendung finden und wie sie Wissen verarbeiten können. Der zweite Unterabschnitt führt die Sprache TyRuBa ein, welche in dieser Arbeit als Anfragesprache für Fakten eines korrespondierenden Modells benutzt wird Allgemein Logikprogrammiersprachen, wie beispielsweise PROLOG [PROLOG] oder TyRu- Ba [TyRuBa], gehören den Programmiersprachen der fünften Generation an. Sie finden ihren größten Einzug in der Welt der künstlichen Intelligenz. Dort werden Logikprogramme in Agenten verwendet, die aufgrund von gelerntem Wissen über ihre Umgebung selbst eine geeignete Reaktion auf ein Ereignis finden können. Die ersten theoretischen Grundlagen sind um 1970 gelegt worden, und durch das Fifth Generation Project im Jahre 1982 hat man Logikprogrammierung dafür eingesetzt, natürliche Sprache zu erkennen, Texte zu analysieren sowie Bilder und Grafiken zu verstehen. Das Programm selbst soll keine Daten, sondern Wissen verarbeiten. Logikprogrammiersprachen unterscheiden sich stark zu den imperativen Sprachen wie C, C++ oder Java, da sie keine Kontrollstrukturen wie Schleifen aufweisen. Ein Logikprogramm besteht meist aus zwei wichtigen Komponenten: Zum einen aus der Wissensbasis, die Aussagen über eine bestimmte Domäne hält, und zum anderen dem Interpreter. Letzterer wertet Anfragen an die Wissensbasis aus und gibt die Ergebnisse der Anfrage zurück. Der Interpreter ist die Komponente des 14

23 2.4 Logikprogrammierung Programms, mit der der Benutzer agiert, um Wissen verarbeiten zu können. Stellt ein Benutzer eine Anfrage an die Wissensbasis, so versucht das Programm eine gültige Lösung aus der Wissensbasis mit der Hilfe eines Inferenzalgorithmus abzuleiten und das Resultat auszugeben. Die Funktionsweise dieser Ableitung führt auf die Darstellung des Wissens eines Logikprogramms. Wissen lässt sich im Allgemeinen als Kenntnis über etwas bezeichnen und wird durch prädikatenlogische Formeln ausgedrückt. Diese Formeln bestehen aus einer Menge von Prädikaten, Konstanten, Variablen, Junktoren (,, ) und Quantoren (, ). Während bei der Aussagenlogik eine Aussage als Einheit logisch überprüft wird, untersucht die Prädikatenlogik auch die innere Struktur dieser Aussage, also die Beziehung der Parameter des Prädikats zueinander. Prädikatenlogik erweitert somit die Aussagenlogik und schließt diese ein. Ein Prädikat drückt also zwischen Konstanten und Variablen eine innere Struktur aus und gibt ihr eine Bedeutung. Ein Prädikat kann beispielsweise eine Beziehung zwischen Vater/Mutter und Sohn/Tochter ausdrücken, wie die Tabelle 2.1 bereits in Syntax von TyRuBa zeigt. Aussage Hans ist Vater von Peter Hans ist Vater von Petra Frank ist Vater von Klaus Ulrike ist Mutter von Peter Ulrike ist Mutter von Petra Uta ist Mutter von Ulrike Prädikat istvatervon(hans, Peter). istvatervon(hans, Petra). istvatervon(frank, Klaus). istmuttervon(ulrike, Peter). istmuttervon(ulrike, Petra). istmuttervon(uta, Ulrike). Tabelle 2.1: Fakten, die die Eltern von Kindern beschreiben Es sei angemerkt, dass in diesem Beispiel nur Konstanten verwendet worden sind. Der. dient dem Abschluss des Prädikats. Solche Prädikate werden in Logiksprachen Fakten genannt. Bei einer Anfrage an die Wissensbasis, versucht das Programm durch Ableiten immer auf diese Fakten zu schließen. Die Tabelle 2.2 zeigt erste Anfragen an die Wissensbasis und welche Lösungen der Interpreter ausgibt. Das Symbol :- stellt dabei die Einleitung einer Anfrage dar und das? kennzeichnet eine Variable. Eine erfolgreiche Ausgabe bedeutet, dass eine Lösung für die Anfrage aus den Fakten hergeleitet werden konnte. Die erste Anfrage aus der Tabelle wird durch die Inferenz mit einem Erfolg bestätigt, da der Fakt, dass Hans der Vater von Peter ist, direkt in der Wissensbasis steht. Die zweite Anfrage kann 15

24 2 Grundlagen Anfrage Interpreteranfrage Interpreterausgabe Ist Hans der Vater :-istvatervon(hans, Peter). Ja von Peter? Ist Frank der Vater :-istvatervon(frank, Petra). Nein von Petra? Wer ist Mutter von :-istmuttervon(?mutter,?mutter = Ulrike Peter? Peter). Welche Kinder hat Hans? :-istvatervon(hans,?kinder).?kinder = Peter;?kinder = Petra Tabelle 2.2: Verschiedene Anfragen an eine Wissensbasis allerdings nicht aus den Fakten abgeleitet werden und ergibt somit einen Fehlschlag. Interessant ist jetzt die dritte Anfrage. Hier wurde eine Variable benutzt, die nach Abarbeitung der Anfrage, einen Wert als Lösung zugewiesen bekommt. Diese Variable bekommt ihren Wert durch eine sogenannte Unifikation, einer Variablenverschmelzung, zugewiesen, bei der das Programm versucht die Variable durch eine gültige Konstante zu ersetzen. Dabei sucht der Inferenzalgorithmus die Fakten der Wissensbasis von oben nach unten ab und sucht nach einem passenden Fakt für die Unifikation. Im Beispiel stehen sich hier die Fakten istmuttervon (Ulrike,Peter) und istmuttervon(?mutter,peter) gegenüber. Ihre Gleichheit gilt nur, wenn sich für die Variable?mutter eine geeignete Ersetzung durch eine Konstante findet, was mit der Lösung?mutter = Ulrike der Fall wäre. Der Fakt istmuttervon(ulrike,petra) wird daher nicht betrachtet, weil die letzte Konstante unterschiedlich ist, auch wenn der Prädikatname übereinstimmt. Die letzte Anfrage zeigt für das Ergebnis zwei mögliche Unifikationen der Variablen?kinder an. Das ist auch klar, da laut den Fakten sowohl Peter als auch Petra Kinder von Hans sind. Das Beispiel lässt sich jetzt so erweitern, dass überprüft werden soll, ob es eine Person gibt, die ein Großelternteil ist und gegebenenfalls ihre Enkelkinder herausgefunden werden sollen. Natürlich ließen sich an dieser Stelle viele weitere Fakten in die Wissensbasis aufnehmen, doch bietet ein Logikprogramm hier die Möglichkeit Regeln zu definieren, die Prädikate in Beziehung zueinander setzen, um auf Fakten schließen zu können. Formal ausgedrückt ist eine Person dann Großelternteil, wenn sie mindestens ein Kind besitzt und jenes wiederum ein Elternteil seiner Kinder ist. Eine solche Dann-Wenn-Aussage zeigt das Listing 2.1. Eine Regel baut sich aus Regelkopf und Regelrumpf auf. Der Regelkopf gilt genau 16

25 2.4 Logikprogrammierung 1 großeltervonenkel (? großelter,? enkel ) :- 2 eltervonkind (? großelter,? elter ), 3 eltervonkind (? elter? enkel ). 4 5 eltervonkind (? elter,? kind ) :- 6 istvatervon (? elter,? kind ) ; 7 istmuttervon (? elter,? kind ). Listing 2.1: Beispielregeln für Verwandtschaftsbeziehungen dann, wenn der Regelrumpf erfolgreich abgeleitet werden konnte. Dies ist entspricht einer Implikation, die sich im Beispiel durch das Zeichen :- wiederfindet: Regelkopf :- Regelrumpf oder Regelkopf Regelrumpf oder auch Regelkopf Regelrumpf. Für die Überprüfung, ob es in der Wissensbasis einen Großelternteil gibt, sind die Regeln für eine Großelter-Enkel- und Elter-Kind-Beziehung definiert worden. In den meisten Logiksprachen, so wie auch in TyRuBa, steht ein ; für eine Disjunktion und das, für eine Konjunktion. Die zweite Regel des Listings 2.1 drückt aus, dass eine Person dann ein Elter von einem Kind ist, wenn die Person entweder Vater oder Mutter von diesem Kind ist. Sie wird von der ersten Regel benutzt, um zu einer Person das Kindes-Kind zu ermitteln. Sie sagt aus, dass eine Person dann einen Enkel hat, wenn sie ein Elternteil eines Kindes ist und dieses Kind wiederum ein Elternteil eines Kindes ist, welches folglich ein Enkelkind ist. Stellt nun der Benutzer die Anfrage :- großeltervonenkel(uta,?enkel)., weil er die Enkelkinder von Uta erfragen möchte, so muss der Inferenzalgorithmus aus den Regeln auf andere Regeln und Fakten schließen, um eine Lösung abzuleiten. Hierbei ergibt sich ein Ableitungsbaum, wie er in Abbildung 2.5 gezeigt ist. Der Inferenzalgorithmus schreitet einen Regelrumpf ab und versucht jede weitere enthaltene Regel erfolgreich abzuleiten. Ist dies nicht möglich, so wendet der Inferenzalgorithmus Backtracking an, mit dem er einen Schritt zurückgeht und für eine bereits erfolgreich abgeleitete Regel eine andere Lösung findet. Es bleibt jetzt nur noch zu klären, was eine gültige Lösung bedeutet. Eine Lösung einer Anfrage an ein Logikprogramm ist die Menge aller Unifikationen, bei der Variablen Konstanten zuweisen werden. Der sogenannte Most General Unifier (MGU) ist ein Begriff aus de Logik, welcher die allgemeinste Ersetzung der Variablen durch Konstanten repräsentiert, siehe auch [RuNo04]. Auf der Wissensbasis einer Logikprogrammiersprache gibt es meist die Einschränkung, dass alle prädikatenlogischen Formeln als Horn-Klauseln geschrieben werden. 17

26 2 Grundlagen Abbildung 2.5: Ableitungsbaum der Anfrage :-großeltervonenkel(uta,?enkel). So eine Klausel besteht aus einer Disjunktion von Literalen, Prädikaten. Das besondere an ihr ist, dass sie maximal ein positives Literal besitzt und alle anderen Literale negiert sind. Das bietet zum einen den Vorteil, dass jede Horn-Klausel als Implikation geschrieben werden kann und die logische Konsequnenz mit Horn- Klauseln kann in einer Zeit ermittelt werden, die linear zur Größe der Wissensbasis ist. [RuNo04] S. 276ff. Aus der Tatsache, dass sich jede dieser Klauseln als Implikation schreiben lässt, folgt schnell die Definitionen für das Aussehen von Fakten, Regeln und Anfragen in einer Logikprogrammiersprache, wie es in Tabelle 2.3 dargestellt ist. Horn-Klausel Implikation in Logik Bedeutung A B C A (B C) A :- B,C. Regel (max. ein positives Literal) A A f alsch A. Fakt (nur ein positives Literal) A wahr A :-A. Anfrage (kein positives Literal) Tabelle 2.3: Interpretation von Fakten, Regeln und Anfragen als Hornklauseln Die Tabelle zeigt eine allgemeine Horn-Klausel, die in eine Implikation umgewandelt wird, und wie diese in der Notation einer Logikprogrammiersprache aussieht. Der Inferenzalgorithmus beruht meist auf dem Resolutionskalkül. Dieser Kalkül ist eine Vorschrift, wie Klauseln zu ersetzen sind, um eine Logikanfrage auf ihre Wahrheit hin zu prüfen. Der Resolutionskalkül ist widerlegungsvollständig. Das 18

27 2.4 Logikprogrammierung heißt, wenn zu einer gegebenen Menge an prädikatenlogischen Formeln, Klauselmenge genannt, eine Formel, die die Anfrage darstellt, negiert in die Klauselmenge aufgenommen wird, so lässt sich dann die leere Klausel ableiten, wenn die Anfrage wahr ist. Zwei Klauseln können dann resolviert werden, wenn ein Literal der einen Klausel negiert in der anderen Klausel vorkommt. Es ergibt sich dabei entweder die leere Klausel oder wieder eine Klausel. Damit jeweils zwei Klauseln resolviert werden können, ist es nötig, Variablen und Konstanten innerhalb der Literale zu substituieren (Unifikation). Dies gibt die folgende Formel an: P (x) Q(x), P (z) R(y) Q(z) R(y) mit θ = x/z In der ersten Klausel existiert das Prädikat P (.), welches in der zweiten negiert auftritt. Diese Klauseln können durch den Resolutionskalkül zu Q(z) R(y) resolviert werden, wenn für die Substitution θ gilt, dass x durch z ersetzt wird TyRuBa TyRuBa ist ein Akronym für Type Rule Base und ist eine Logikprogrammiersprache mit PROLOG [PROLOG] ähnlicher Syntax. Während die meisten Sprachen mit ungetypten Konstanten und Variablen, sogenannten Atomen, arbeiten, bietet TyRuBa die Möglichkeit, die Parameter eines Prädikats zu typisieren. Die Typisierung bringt den Vorteil mit sich, dass ein Großteil möglicher Lösungen allein durch ihren Typ eingeschränkt wird. Abbildung 2.6 zeigt einen Lösungsraum für das Prädikat human(...), das als Parameter einen String zulässt. Bei einer Anfrage nach diesem Prädikat, würden alle Lösungsmöglichkeiten in Betracht gezogen werden. Allerdings muss nur eine Teilmenge aller Lösungen betrachtet werden, da nur manche Lösungen auf String getypt sind. Dies gibt der String-Kreis in der Abbildung an. Da es keine Schnittmenge mit den Integer-getypten Lösungen gibt, brauchen diese nicht weiter betrachtet werden. Allerdings besitzt der Stringkreis eine Schnittmenge mit Lösungen des Objectkreises. String und Object haben deswegen eine Schnittmenge, da String von Object erbt und Object somit den Typ String als Teilmenge besitzt. Der Vererbungsmechanismus ist auch der Ansatzpunkt für den Benutzer, neue Typen zu definieren, indem er von einem bereits existierenden Typ ableitet. Das Listing 2.2 zeigt die Definition von Typen, die beispielsweise für die Repräsentation eines Graphen benutzt 19

28 2 Grundlagen Abbildung 2.6: siehe [TyRuBa] werden könnten. 1 TYPE Graph AS String 2 TYPE Knoten AS String 3 TYPE Kante AS String Listing 2.2: Eigene Typdefinitionen Hierbei sind alle neu definierten Typen implizit auch Strings, das heißt ein Prädikat, das als Parameter Strings erlaubt, würde auch den Typ Graph akzeptieren. Prädikate müssen, bevor sie benutzt werden, auch definiert werden. Dabei gibt der Benutzer an, wie viele Parameter das Prädikat hat, was ihre Typen sind und legt zusätzlich MODES fest, die den Inferenzalgorithmus beeinflussen. Ein Prädikat, das ausdrückt, dass eine Person in einer Stadt lebt, sei wie in Listing 2.3 definiert. Der erste Parameter gibt dabei den Namen der Person an und der zweite Parameter den Namen der Stadt, in der diese Person lebt. Beide Parameter sind vom Typ String und folgen auf ein ::, das dem Prädikatnamen folgt. Die Anzahl der Parameter wird durch die Anzahl an Typen definiert, die angegeben werden. Nun folgt ein wichtiger Abschnitt in der Prädikatdefinition, der sich von an anderen Logiksprachen unterscheidet. Ein Prädikat kann verschiedene Modi haben, 20

29 2.4 Logikprogrammierung 1 livesin :: String, String 2 MODES 3 (B,F) IS SEMIDET 4 (F,B) IS NONDET 5 END Listing 2.3: Eigene Prädikatdefinition die vorschreiben, wie der Inferenzalgorithmus von TyRuBa das Prädikat abarbeiten soll. Je nach Konstellation von freien (f-free) oder gebundenen (b-bound) Parametern wird in dem Modes-Abschnitt festgelegt, ob der Inferenzalgorithmus nach einer gefunden Lösung abbrechen - Modus SEMIDET - oder nach weiteren Lösungen suchen soll - Modus NONDET. Es ist schnell zu erkennen, dass der semideterministische Modus zu einem frühzeitigen Abbrechen der Suche führt und nicht noch weitere Lösungen sucht, was Suchzeit spart. Das Listing 2.4 zeigt zur Erläuterung der Modi ein Codebeispiel. 1 livesin (" Frank "," Clausthal "). 2 livesin (" Frank "," Zellerfeld "). 3 livesin (" Sabine "," Clausthal "). 4 5 :- livesin (? person," Clausthal "). 6 :- livesin (" Frank ",? stadt ). Listing 2.4: Beispiel der für die Modi des Inferenzalgorithmus Die erste Anfrage hat einen freien Parameter?person und einen gebunden Parameter Clausthal. Also wird der nicht-deterministische ((F,B) IS NONDET) Inferenzalgorithmus ausgeführt. Als Lösung wird TyRuBa die Konstanten Frank und Sabine vorschlagen, da erschöpfend gesucht wird. Anders hingegen ist die zweite Anfrage, die fragt, in welcher Stadt Frank wohnt. Hier ist der erste Parameter gebunden und der zweite frei und der Modus somit semi-deterministisch ((B,F) IS SEMIDET). Der Inferenzalgorithmus wird als Lösung für die Variable?stadt die Konstante Clausthal ausgeben und die Suche beenden, obwohl Zellerfeld ebenso eine korrekte Lösung wäre. In TyRuBa gibt es neben dem semi-deterministischen und nicht-deterministischen Modus noch den deterministischen und den multi- Modus. Ein Prädikat, das semideterministisch ist, kann fehlschlagen oder sein frei- 21

30 2 Grundlagen er Parameter wird genau mit einer Konstante gebunden. Ist der Modus hingegen deterministisch, sagt dies aus, dass es nicht fehlschlagen wird und der freie Parameter genau mit einer Konstante gebunden wird. Der nicht-deterministische Modus kann fehlschlagen oder für die freien Parameter beliebig viele Lösungen binden. Der Multi-Modus letztlich kann nicht fehlschlagen und die Parameter des Prädikats werden mit mindestens einer Lösung gebunden. Die Tabelle 2.4 zeigt die Modi noch einmal im Überblick. Modus #Lösungen DET = 1 SEMIDET 1 NONDET 0 MULTI 1 Tabelle 2.4: Inferenzmodi in Abhängigkeit zu der Anzahl ihrer Lösungen Wenn TyRuBa Regeln oder Anfragen bearbeitet, so werden zuvor die Prädikate dieser Regel oder Anfrage überprüft, ob sie auch mit den angegebenen Modi benutzt werden können. Andernfalls ordnet TyRuBa diese Prädikate innerhalb der Regel oder Anfrage neu an, so dass jeder Modus erfüllt werden kann. Falls eine Neuanordnung nicht möglich ist, meldet das Logikprogramm einen Fehler und kann dadurch dem Benutzer anzeigen, dass die deklarierten Modi eventuell falsch festgelegt sind. Dieser Fehler muss allerdings nicht benutzerseitig entstanden sein, sondern kann auch daher zu Stande kommen, weil es für TyRuBa nicht offensichtlich ist, dass ein deklarierter Modus tatsächlich in der festgelegten Form nutzbar ist. Dieser Fehler ist also systembedingt. Der Benutzer hat hier die Möglichkeit das Schlüsselwort REALLY in der Modusdeklaration zu verwenden. When TyRuBa encounters a REALLY declaration, it only checks that there exists legal execution modes for all subexpressions but does not check that the declared execution mode returns less result than the inferred mode. [TyRuBa]. Das Listing 2.5 zeigt eine Beispielanfrage mit einem Existenzquantor, die fragt, ob es eine Stadt gibt, für die keine Person existiert, die in ihr lebt. 1 :- city (? city ), NOT ( EXISTS?x : livesin (?x,? city )). Listing 2.5: Anfrage mit Existenzquantor 22

31 2.4 Logikprogrammierung Der Existenzquantor definiert in seinen umschließenden Klammern lokal Variablen, die nach außen nicht sichtbar sind. Allerdings können außerhalb der Klammern gebundene Variablen innerhalb der Quantordeklaration verwendet werden. Der Quantor dient der Überprüfung, ob es für eine Variable eine gültige Lösung gibt oder nicht, aber nicht, wie diese aussieht. Im Listing 2.5 würde TyRuBa nur Lösungen für solche Städte ausgeben, in denen niemand lebt, aber nicht die Belegung der Variablen?x anzeigen. 23

32 2 Grundlagen 24

33 3 Common Component Modeling Example Dieses Kapitel führt das Modellierungsbeipspiel CoCoME ein. CoCoME steht für Common Component Modeling Example und ist ein kleines bis mittelgroßes Modell, das allgemein ein Handelssystem für Supermärkte beschreibt, welches den Kassiervorgang und die Lager- und Filialverwaltung unterstützt. Dieses Beispiel weist ein dreischichtiges Informationssystem mit einer Datenhaltungs-, Applikations- und Präsentationsschicht auf, wie es im zweiten Kapitel auf Seite 13 allgemein eingeführt worden ist. Diese Schichtenarchitektur soll aufgrund der Modellgröße die Grundlage einer Überprüfung auf eine strikte Schichtenarchitektur durch das zu entwickelnde Werkzeug bilden. Der erste Abschnitt beschreibt die Entstehung und Motivation von CoCoME, während der zweite Abschnitt das Beispiel in seinen Funktionen näher erläutert. Der letzte Abschnitt geht auf die Architektur und das Design des Beispiels ein und zeigt die Komplexität des Beispielmodells, das für eine Überprüfung auf eine strikte Schichtenarchitektur per Hand zu aufwendig ist. 3.1 Motivation von CoCoME Das Common Component Modeling Example ist von verschiedenen universitären Teams als ein gemeinsames Modellierungsbeispiel auf einem Forschungsseminar in Dagstuhl beschlossen worden, welches mit unterschiedlichen komponentenbasierten Modellierungsansätzen modelliert werden sollte. Der Grund für ein gemeinsames Beispiel ist der, dass es im Forschungsbereich der Komponentenmodelle viele komponentenbasierte Modellierungsansätze gibt, denen zum einen unterschiedliche Beispiele zugrunde liegen und zum anderen ein Ansatz verschiedene Aspekte der Modellierung hervorhebt, was einen Vergleich unter allen Ansätzen schwierig gestaltet. 25

34 3 Common Component Modeling Example Ein Modellierungsansatz fokussiert verschiedene Aspekte, die die formale Modellierung von Komponenten angehen oder Aussagen über die Qualität eines Komponentenmodells erlauben.[cocome](s.1) Zu den formalen Aspekten von Komponentenmodellen gehören: Komposition: Die Art und Weise, wie Komponenten komponiert werden. Es stellt sich die grundlegende Frage, wo beispielsweise Schnittstellen definiert oder wie sie angesprochen werden. Es bietet sich als eine Möglichkeit an, die Komponenten mit ihren Schnittstellen so zu modellieren, dass die Kommunikation zweier Komponentenschnittstellen direkt stattfindet, also Daten und Objekte von einer Quellkomponente über eine Schnittstelle direkt an die Empfängerkomponente weitergereicht werden. Die andere Möglichkeit einer Komposition ist die, falls die kommunizierenden Komponenten in unterschiedlichen Komponenten eingebettet sind, dass Daten und Objekte über Schnittstellen von einer Quellkomponente an die jeweils umschließenden Komponenten delegiert werden und diese an die Zielkomponente weitergereicht werden. Dieses sind strukturelle Unterschiede in der Modellierung. Kommunikation: Komponenten kommunizieren über die Schnittstellen, die sie anbieten und benötigen. Es kann hier zwischen asynchroner und synchroner Kommunikation gewählt werden. Ein synchroner Aufruf unterscheidet sich von einem asynchronen Aufruf dadurch, dass der Ablauf eines Programms erst nach Abarbeitung des Aufrufs fortgeführt wird. Somit ist der aktuelle Programmablauf blockiert. Bei einem asynchronen Aufruf würde die Programmausführung weiter ausgeführt werden, während der Aufruf nebenläufig abgearbeitet wird. Nebenläufigkeit: Dadurch, dass Komponenten sowohl in einem verteilten System als auch mit asynchroner Kommunikation modelliert werden können, treten nebenläufige Kommunikationen im System auf, die behandelt werden müssen, um beispielsweise Daten eines Systems konsistent zu halten. Die Behandlung von Nebenläufigkeiten muss auf Komponentenebene formal durch eine Spezifikation manifestiert werden. Qualitätsaussagende Aspekte bei einer komponentenbasierten Modellierung fokussieren unter anderem folgende Punkte: Vorherige Annahmen: Es können bestimmte Annahmen getroffen werden, die dem Ansatz zugrunde liegen. Middlewareverwendung: Wie wird die verwendete Middleware benutzt und welche Rolle spielt sie im System. 26

35 3.2 Das Modellierungsbeispiel Nebenläufigkeit: Dieser Aspekt klärt die Frage, wie Nebenläufigkeiten im System behandelt werden. Das entwickelte Modellierungsbeispiel ist an die Teams in Form von textuellen Beschreibungen und einer Java-Implementation ausgehändigt worden, damit jedes Team dieselbe Grundlage hatte, seinen Ansatz für die komponentenbasierte Modellierung auf das Beispiel anzuwenden. Zu den textuellen Beschreibungen gehören use cases, along with UML diagrams of the key components and UML sequence diagrams [CoCoME] (S.5). Sie geben die architektonische Struktur vor, sowie das Verhalten des Systems, wie auf Benuntzeraktionen zu reagieren ist und wie Komponenten untereinander kommunizieren. 3.2 Das Modellierungsbeispiel CoCoME ist ein Modellierungsbeispiel, das ein Handelssystem für Supermarktfilialen beschreibt. Das Handelssystem beinhaltet drei große Funktionsgruppen: die Kassiervorgänge, die Verwaltung des Lagerbestandes einer Filiale und die Verwaltung von Statistiken über die Filialen eines Unternehmens umfassen. Die Kassiervorgänge An der Kasse finden die Kassiervorgänge statt. Die Abbildung 3.1 zeigt alle technischen Geräte, die bei diesem Vorgang ihren Einsatz finden. Ein Kunde, der Waren eingekauft, legt diese auf das Kassierband. Ein Kassierer kann nun die Produktnummer jedes Produktes über einen Barcodescanner einlesen oder sie über die Tastatur der Kasse eingeben. Ein lokaler Rechner an der Kasse verarbeitet die vom Scanner gelesenen oder an der Kasse eingegebenen Daten und zeigt auf einem Display das aktuelle Produkt, seinen Preis und die Gesamtkosten aller Waren an. Wenn alle Produkte eingelesen worden sind, kann der Kunde seine Waren entweder in Bar bezahlen oder per Kreditkarte. Danach erstellt der Kassencomputer mit der Hilfe eines angeschlossenen Druckers einen Kassenbeleg für den Kunden und sendet Informationen über die eingekauften Güter an einen Server im Lager, um den Lagerbestand zu aktualisieren. Ein Kassensystem kann sich in einen Expressmodus versetzen, wenn bestimmte Forderungen erfüllt sind, wie beispielsweise, dass in der vergangenen Stunde an dieser Kasse wenige Waren bei einem Kassiervorgang abgebucht worden sind. Dies ermöglicht eine schnellere Abwicklung des Kassiervorgangs. Der Kunde darf in diesem Zustand des Systems nur mit Bargeld zahlen. Der 27

36 3 Common Component Modeling Example Kassierer hat durch einen Knopfdruck an der Kasse die Möglichkeit, das System vom Expressmodus wieder in den normalen Modus zu versetzen. Abbildung 3.1: Die technischen Geräte, die an dem Kassiervorgang eine Rolle spielen Die Lagerverwaltung Ein Filialleiter und ein zuständiger Angestellter für den Lagerbestand haben Zugang zu einem Client-Computer, der über den Server des Warenlagers Informationen über alle Waren im Lager beziehen kann. Dieser Server ist, wie Abbildung 3.2 zeigt, unter anderem mit allen Kassen der Filiale verbunden, damit der Lagerbestand aktuell gehalten werden kann, wenn Waren verkauft worden sind. Der Filialleiter kann sich Berichte anfertigen lassen, die Auskunft über ein bestimmtes Produkt geben, welches nur noch in geringen Mengen vorrätig ist. Er kann für diesen Fall neue Produkte bestellen. Des Weiteren hat er die Möglichkeit, an diesem Computer Preisänderungen für die Produkte vorzunehmen und sich Statistiken bezüglich des Handelssystems ausgeben zu lassen. Der Lagerangestellte nutzt diesen Client-Computer, um neue Waren in das System einzugeben, damit sie nicht nur in der Filiale erhältlich sind, sondern auch im System als verfügbar angezeigt werden können. 28

37 3.3 Architektur und Design von CoCoME Abbildung 3.2: Handelssystem für die Lagerverwaltung Die Filialverwaltung Jeder Lagerserver einer Filiale ist mit einem Server des Unternehmens verbunden, wie Abbildung 3.3 darstellt, welchem alle Filialen zugeteilt sind. Ein Unternehmensleiter kann über einen Client-Computer auf den Unternehmensserver zugreifen und sich Berichte über Lieferzeiten von georderten Waren einer Filiale anfertigen lassen und einsehen. 3.3 Architektur und Design von CoCoME Der erste Unterabschnitt dieses Kapitels zeigt die Architektur des Handdelssystems als Komponentenstrukturdiagramm, welches als Whitebox-Sicht dargestellt ist, um zu sehen, welche Schnittstellen zur Kommunikation der Komponenten untereinander benutzt werden. Des Weiteren werden die Aufgaben der einzelnen Komponenten erläutert. Der zweite Unterabschnitt beschäftigt sich mit dem Designmodell des Modellierungsbeispiels. Es ist aus dem Javacode gewonnen worden, der an die Teams als 29

38 3 Common Component Modeling Example Abbildung 3.3: Handelssystem für die Filialenverwaltung Modellierungsgrundlage ausgegeben worden ist. Das Designmodell beleuchtet dabei noch einmal das dreischichtige Informationssystem innerhalb des CoCoME und zeigt mit einer teilweisen Whitebox-Sicht auf das Modell die Komplexität des Systems und geht auf die Schwierigkeit einer Überprüfung auf eine strikte Schichtenarchitektur ein Architektur Die Architektur des Handelssystems ist mit Komponentenstrukturdiagrammen der UML 2.0 beschrieben worden. Das Handelssystem wird durch die Hauptkomponente Tradingsystem, wie sie in Abbildung 3.4 gezeigt wird, repräsentiert. Sie enthält zwei innere Komponenten Inventory, welche ein Informationssystem darstellen, und CashDeskLine, das ein eingebettetes System darstellt. Die CashDeskLine-Komponente stellt die Funktionen für die Kassiervorgänge an allen Kassen der Supermarktfiliale bereit. Sie ist durch eine Schnittstelle BankIF mit der Bank verbunden, um dem Kunden die Zahlung mit Karte zu ermöglichen. Hierfür kommuniziert die Komponente über diese Schnittstelle mit dem System der Bank. Sie bietet weiterhin eine Schnittstelle SaleRegisteredEvent an, die die Inventory-Komponente benutzt. Die Schnittstelle zeigt dem Inventory durch eine asynchrone Kommunikation ein Event, wie den Start eines Kassiervorgangs, an. 30

39 3.3 Architektur und Design von CoCoME Abbildung 3.4: Die TradingSystem-Komponente Damit der Kassencomputer zu einem Produkt beispielsweise seinen Preis ermitteln kann, benutzt die CashDeskLine-Komponente das vom Inventory angebotene Interface CashDeskConnectorIF, über welches sich Produktinformationen beziehen lassen. Im Folgenden wird die Inventory-Komponente beschrieben und auf sie näher eingegangen, da sie das angesprochene Informationssystem aufweist, das einer Überprüfung des zu entwickelnden Werkzeugs dienen soll. Diese Komponente übernimmt als Teilsystem die Verwaltung aller Waren und Filialen. Abbildung 3.5 zeigt die inneren Komponenten und ihre Schnittstellen, die das Inventory kapselt: GUI: Sei repräsentiert die Präsentationsschicht des Informationssystems. Sie zeigt am Client-Computer verschiedene Berichte über die Filiale oder das Lager an. Eine weitere Funktion bildet eine Nutzerschnittstelle, die der Lagerangestellte oder der Filialleiter zum Bestellen oder Eingeben neuer Waren benutzen kann. Die GUI-Komponente nutzt hier die Schnittstellen ReportingIf und StoreIf der Applikationsschicht, die die Funktionen der Interfaces bereitstellt. Die Komponente selber bietet kein Interface an. Application: Diese Komponente stellt die Applikationsschicht dar. Sie implemen- 31

40 3 Common Component Modeling Example tiert die Logik des Teilsystems und stellt auf Anfrage Berichte bereit, reagiert auf Ereignisse an den Kassen und greift auf die Datenhaltung zu, um aus dem aktuellen Warenbestand Statistiken anfertigen zu können. Die Komponente definiert die Schnittstellen CashDeskConnectorIf, mit der die Kassen Produktinformationen beziehen können, ReportingIf, die der GUI- Komponente verschiedene Funktionen der Berichterstellung zur Verfügung stellt, und StoreIf, mit der ein Filialenleiter über die GUI-Komponente neue Produkte bestellen oder ihren Preis ändern kann. Die Applikationskomponente nutzt die von der Datenhaltungsschicht angebotenen Schnittstellen der Datenhaltungskomponente für die Speicherung von Daten und reagiert auf Ereignisse der SaleRegisteredEvent-Schnittstelle. Alle angebotenen Schnittstellen der Applikationsschicht, die mit der GUI- Komponente kommunizieren, sind Service-orientiert. Das bedeutet, dass [... ] so called Transfer Objects are defined which are used for data transfer [CoCoME](S.32). Damit werden also keine Objektreferenzen weitergereicht, sondern Transferobjekte, die eine Kopie der Originalobjekte sind [Fowl02]. Der Zugriff auf die Objekte der Datenhaltungskomponente geschieht hingegen über Objektreferenzen, da die dort angebotenen Schnittstellen Objektorientiert sind. Data: Die Data-Komponente spiegelt die Datenhaltungsschicht wider. Sie stellt die Schnittstellen EnterpriseQueryIf, PersistenceIf und StoreQueryIf bereit, die Datenbankanfragen der Applikationskomponente erlauben. Allerdings ist diese Komponente nicht die Datenbank, in der alle Daten des Systems gehalten werden. Hierfür wird die Data-Komponente durch die Database-Komponente komplettiert, mit der sie kommunizieren kann. Database: Diese Komponente repräsentiert die Datenbank, in der alle systemrelevanten Daten abgelegt und gelesen werden können. Die Kommunikation zwischen der Datenbank-Komponente und der Data-Komponente wird durch JDBC [SUNMic] und der Middleware Hibernate[RHMJBo], die Objekte in ein datenbankspezifisches Format transformiert, verwaltet. Die Anordnung dieser Komponenten zeigt eine Schichtenarchitektur, die strikt ist, da eine übergeordnete Komponente jeweils die Schnittstellen einer darunterliegenden Komponente benutzt. Diese Eigenschaften gilt es für einen Softwareentwickler zu wahren, wenn er das Designmodell entwirft, wie es im nächsten Unterabschnitt vorgestellt wird. 32

41 3.3 Architektur und Design von CoCoME Abbildung 3.5: Die inneren Komponenten und Schnittstellen der Inventory- Komponente Design Das Designmodell ist durch den ausgelieferten Java-Code an die Teams bestimmt worden. Hierfür sind die Komponenten im Code als Pakete repräsentiert, da Java keine Abbildungsmöglichkeit für Komponenten auf Codeebene bereit hält. Java- Pakete eignen sich deswegen, weil sie ähnlich zu Komponenten Modellelemente wie Klassen und Schnittstellen, die die Funktionen eines Systems realisieren, kapseln können. Des Weiteren können Pakete Unterpakete enthalten, so wie Komponenten innere Komponenten definieren können. Das Designmodell wurde aus dem Java- Code mit Hilfe von Topcased[TopOrg] durch reverse engineering gewonnen. Aus dem Code ergibt sich das in Abbildung 3.6 gezeigte Klassendiagramm, das die Abhängigkeiten der Pakete zeigt, die die Schichten des Informationssystems in CoCoME darstellen. Die Abbildung zeigt bereits, dass die Richtung der Abhängigkeiten der Schichten, 33

42 3 Common Component Modeling Example Abbildung 3.6: Paketdiagramm, das äquivalent zum Architekturmodell ist bzw. der Pakete innerhalb der Schichten, mit den Abhängigkeitsbeziehungen des Architekturmodells korrespondieren. Das gezeigte Modell in der Abbildung 3.6 ist stark vereinfacht und zeigt nicht, weshalb die Pakete voneinander abhängen. Die Abbildung 3.7 hingegen zeigt eine White-Box-Sicht des Modells und fokussiert dabei auf einen Teil der Modellelemente, die eine schichtenübergreifende Beziehung mit anderen Elementen eingehen. Alle anderen Modellelemente werden in diesem Diagramm aus Gründen der Übersicht ausgelassen. Somit zeigt es keine Abhängigkeiten zwischen Modellelementen, die mit einem Typen eines anderen Modellelements typisiert sind. Dennoch ist in diesem Diagramm die Komplexität erkennbar, die sich mit größer werdendem Modell ebenfalls erhöht. Eine hohe Komplexität lässt kaum eine Aussage darüber zu, ob ein gegebenes Designmodell noch den Anforderungen des Architekturmodells entspricht. Dies erörtert nochmals die Motivation, ein Modell mit einem anderen Formalismus darzustellen, welcher zudem einen Anfragemechanismus bereitstellt. 34

43 3.3 Architektur und Design von CoCoME Abbildung 3.7: Ein Teil des kompletten Designmodells, der auf die schichtenübergreifenden Beziehungen zwischen Elementen eingeht 35

44 3 Common Component Modeling Example 36

45 4 Ansatz Dieses Kapitel befasst sich mit dem Hauptteil der Arbeit. Es ist in zwei wichtige Bereiche unterteilt, nämlich die Konzeption einer Modelltransformation von einem Modell der UML in ein äquivalentes Modell, das durch die Fakten einer Logikprogrammiersprache ausgedrückt wird und zum anderen die Konzeption von Regeln, die eine Überprüfung des Modells auf eine strikte Schichtenarchitektur gestatten. Der erste Teil fokussiert dabei hauptsächlich auf die Konzeption und Vorgehensweise für die einzelnen Transformationsschritte und nicht auf die konkrete Umsetzung einer Implementation. Dies wird das Kapitel 5 behandeln. 4.1 Konzeption der Modelltransformation Dieser Abschnitt erläutert in drei Unterabschnitten, wie Prädikate allgemein beschrieben werden können, damit sie ein Modell als Fakten repräsentieren, wie diese Prädikate konkret mit der Hilfe der EMOF generiert werden und sie zu der Erzeugung von Modell-dartellenden Fakten verwendet werden Konzeption von Prädikaten für UML-Elemente Ein Modell, das in einer Wissensbasis eines Logikprogramms dargestellt werden soll, muss vollständig durch entsprechende Fakten abgebildet werden. Das heißt, es dürfen keine Informationen verloren gehen, da dies zu einer anderen Interpretation des Modells führt. Es stellt sich hier die entscheidende Frage, wie welche Modellelemente abgebildet werden müssen und welche Informationen dabei eine wichtige Rolle spielen, zumal es in einer Logiksprache kein Metamodell zur Beschreibung eines Modells in Fakten gibt. Es wird der erste Schritt für die Modelltransformation sein, hier ein Metamodell zu definieren, das jede mögliche Metaklasse der UML und seine Beziehungen und Eigenschaften zu anderen Elementen formal in Prädikate überführt. 37

46 4 Ansatz Die Abbildung 4.1 zeigt ein minimales UML-Modell mit einer Klassenhierarchie aus dem CoCoME-System. Es dient im folgenden der Veranschaulichung, wie modellbeschreibende Prädikate für ein Modell aussehen können. Das Beispiel der Abbildung zeigt die Klasse StoreWithEnterpriseTO, die eine Spezialisierung der Klasse StoreTO ist, einmal in konkreter Syntax und einmal in abstrakter Syntax, um die beteiligten Metaklassen der Generalisierungsbeziehung zu zeigen. Abbildung 4.1: Ein kleines hierarchisches Modell Das minimale Beispiel zeigt bereits, dass für kleine Modelle mehrere Metaklasseninstanzen erzeugt werden müssen sowie auch ihre Metaattribute mit Werten belegt und Metaassoziationen instanziert werden müssen. Es genügt also nicht, Prädikate für jeweils eine Classund eine Generalization, also für eine Metaklasse zu formulieren. Es müssen weiterhin Metaattribute, wie im Minimalbeispiel der Klassenname oder der Aggregationstyp des Klassenattributs, und Metaassoziationen, wie beispielsweise general oder specific, gesetzt werden. Dabei sei angemerkt, dass das Minimalbeispiel weiterhin nur einen Teil aller Metaklassen, Metaattribute und Metaassoziationen zeigt. Das führt zu einer Lösungsidee, die die Stelligkeit der zu verwendenen Prädikate bestimmt, denn jedes UML-Modell besteht aus Instanzen dieser drei Grundelemente: 38

47 4.1 Konzeption der Modelltransformation Metaklassen: Jedes Modellelement einer Metaklasse kann durch ein einstelliges Prädikat repräsentiert werden. Der Parameter des Prädikats stellt dabei einen einmalig im Modell auftretenden Index dar, der nur diesem Element zugewiesen ist. Metaattribute: Eine Metaklasse besitzt Metaattribute, wie beispielsweise der Name einer Klasse, eines Attributs oder einer Assoziation. Daher sollte ein Prädikat regeln, welche Metaklasse in welcher Beziehung zu dem Inhalt eines Metaattributs steht. Es genügt hierfür ein zweistelliges Prädikat. Metaassoziation: Metaassoziationen können ebenso wie Metaattribute mit einem zweistelligen Prädikat behandelt werden, nur drücken sie in diesem Fall eine Beziehung zwischen zwei Metaklassen aus. Der Grund, warum nur diese drei Grundelemente behandelt werden, liegt im Meta- Metamodell, das diese Elemente definiert. Dies spielt bei der Generierung der Prädikate eine tragende Rolle und wird im nächsten Abschnitt erläutert. Abbildung 4.2: Nummerierung aller Modellelemente Die Abbildung 4.2 fokussiert auf die abstrakte Syntax des Modells aus Abbildung 4.1, die die Generalisierungsbeziehung zwischen den Klassen StoreTO und Store- WithEnterpriseTO fokussiert. Jedes Modellelement ist hier mit einem eindeutigen Index versehen, anhand dessen Beispielfakten betrachtet werden können: Einstellige Metaklassen: Class(1), Class(3), Generalisation(2) Implizite einstellige Metaklassen: Classifier(1),Classifier(2),Type(1),Type(2), DirectedRelationship(2) und noch weitere, die sich aus der Vererbungshierarchie des UML-Metamodells ergeben Zweistellige Metaattribute: name(1, StoreTO ),name(3, StoreWithEnterpriseTO ) Zweistellige Metaassoziationen: general(2,1),specific(2,3), generalization(3,2) 39

48 4 Ansatz Die impliziten Metaklassen ergeben sich aus den Vererbungsbeziehungen innerhalb des UML-Metamodells. So ist beispielsweise Class eine Spezialisierung von Classifier, dieser wiederum eine von Type und Namespace. Jede Metaklasse erbt somit implizit von Element. Ein Fakt wie name(3, StoreWithEnterpriseTO ) drückt also aus, dass ein Element mit dem Index 3 einen Namen trägt, der StoreWithEnterpriseTO lautet. Der Fakt der Metaassoziation general mit den Parametern 2 und 1 besagt, dass eine Generalisierung mit dem Index 2 eine gerichtete Beziehung zu einem Element mit dem Index 1 eingeht, welches bei einer Vererbung das allgemeinere Element darstellt. Damit ist geklärt, welche Stelligkeit der Prädikate sinnvoll ist. Allerdings gehört zu einer Prädikatdefinition in TyRuBa auch die Angabe der Modi für den Inferenzalgorithmus (siehe Seite 18). Für Metaklassen können hier nur zwei Modi definiert werden, da das Prädikat einstellig ist und nur zwei verschiedene Modi angegeben werden können. Trivialerweise ist es angebracht, einen nicht-deterministischen Inferenzalgorithmus zu benutzen, wenn es sich bei dem Parameter um eine Variable handelt und anderenfalls bei einer Konstanten den Modus auf semi-deterministisch zu setzen, da eine nicht erfolgreiche Inferenz bei einer Anfrage möglich ist. Anderenfalls gibt die Ableitung einer Anfrage nach einem bestimmten Modellelement einen Erfolg als Lösung aus. Für die Modi eines Prädikats für ein Metaattribut lässt sich folgende Überlegung finden: Metaattribute werden von jeder Metaklasse genau einmal definiert. Es gibt im gesamten UML-Metamodell nicht eine Metaklasse, die ein Metaattribut mit einer Multiplizität > 1 definiert. Das bedeutet für den Inferenzalgorithmus, dass er für eine bekannte Metaklasse nur einmal den Inhalt des Metaattributs finden kann oder gar nicht und das unabhängig davon, ob der zweite Parameter, der den Inhalt angibt, eine Variable oder eine Konstante ist. Konkret heißt dies, dass beispielsweise eine Instanz von Class nicht zwei verschiede Metaattribute name haben kann, sondern nur einen Namen besitzt. Für diesen Fall ist ein semi-deterministischer Modus zu wählen. Gemäß dem Fall, dass es sich bei dem erstem Parameter um eine Variable handelt, muss unabhängig von der Belegung des Inhalts vom Metaattribut der Modus nicht-deterministisch sein, da der Inhalt des Metaattributs entweder durch keine Metaklasse oder durch mindestens eine deklariert sein kann. Bei der Metaassoziation ist der Modus für den Inferenzalgorithmus bei zwei gebundenen Parametern auf semi-deterministisch zu setzen, da für diese entweder ein Fakt vorhanden ist oder nicht. Für die restlichen drei Fälle ergibt sich die Wahl des Inferenzmodus je nach Multiplizität der Metaassoziation. Folgende Fälle von Multiplizitäten können auftreten: 40

49 4.1 Konzeption der Modelltransformation 0..1: Dies entspricht dem Fall der Metaattribute. Ist der erste Parameter, der die Metaklasse der Beziehung darstellt, bekannt, so ist der Modus semideterministisch zu wählen, da entweder eine Lösung existieren wird oder nicht. 1..1: Diese Multiplizität drückt aus, dass eine Metaassoziation genau ein Zielelement besitzt, das sie referenziert. Der Modus ist daher deterministisch, da nur eine Lösung gefunden werden kann und auf jeden Fall auch gefunden wird. 1..*: Für diesen Fall lautet die Modusdefinition abhängig von der Bindung des ersten Parameters entweder multi, für einen konstanten Parameter, oder nichtdeterministisch, für einen freien Parameter. m..n: Für alle anderen Fälle von Multiiplizitäten, die noch nicht abgedeckt sind, wobei 0 m n gilt, gilt, dass unabhängig von der Bindung des ersten Parameters, der Modus in jedem Fall nicht-deterministisch ist, da sowohl für einen gebundenen ersten Parameter keine oder mehrere Lösungen gefunden werden können als auch für einen freien ersten Parameter keine oder mehrere Lösungen aus den Fakten abgeleitet werden können. Das Listing 4.1 zeigt noch einmal informell eine allgemeine Prädikatdefinition, wobei die Definition des Metaassoziationsprädikats ein hier den Fall mit drei nichtdeterministischen Modi zeigt Generierung von Prädikaten Der nächste Schritt für die Modelltransformation ist es, mit den konzeptionierten Prädikaten ein Metamodell zu definieren, mit dem sich die Fakten für das äquivalente Modell erstellen lassen. Dabei ist zu klären, welche Prädikate nötig sind und wo sie her kommen sollen. Eine Generierung des Metamodells von Hand ist hierbei nicht angebracht, da im EMF das UML-Metamodell aus 246 Metaklassen, 106 Metaattributen und 477 Metaassoziationen besteht, was insgesamt 829 Prädikaten entspricht. Weiterhin ist das Werkzeug auch für beliebige Metamodelle ausgelegt, wie es in Kapitel 1 bereits erwähnt worden ist, so dass unter Umständen noch mehr Prädikate erzeugt werden müssen, als im UML-Metamodell, und Prädikate nicht allgemein definiert werden können, sondern abhängig von dem Metamodell sind. Diese Arbeit fokussiert auf das UML-Metamodell. 41

50 4 Ansatz 1 pred_metaklasse :: Metaklasse // Index 2 MODES 3 (B) IS SEMIDET 4 (F) IS NONDET 5 END 6 7 pred_metaattribut :: Metaklasse, Metaattribut // Index, Inhalt 8 MODES 9 (B,B) IS SEMIDET 10 (B,F) IS SEMIDET 11 (F,B) IS NONDET 12 (F,F) IS NONDET 13 END pred_metaassoziation :: Metaklasse, Metaklasse // Index 1, Index 2 16 MODES 17 (B,B) IS SEMIDET 18 (B,F) IS NONDET 19 (F,B) IS NONDET 20 (F,F) IS NONDET 21 END Listing 4.1: Informelle Prädikatdefinition Für die Generierung der Prädikate ist ein Blick in die Essential MOF sehr hilfreich, denn als Meta-Metamodell ist sie die beschreibende Sprache des UML- Metamodells, wie bereits erwähnt worden ist. Abbildung 4.3 zeigt einen Auszug aus der Essential MOF. Jede Metaklasse des UML-Metamodells ist eine Instanz von Class des Meta-Metamodells, also der EMOF. Die Abbildung der EMOF zeigt die Meta-Metaassoziationen ownedattribute der Class, die die beschreibenden Elemente der Metaassoziationen beziehungsweise Metaattribute sind. Als kleines Beispiel sei erwähnt, dass die Metaklasse NamedElement ein Attribut mit dem Namen name besitzt. Als Instanz des Meta-Metamodells bedeutet das, dass NamedElement auf Ebene der 42

51 4.1 Konzeption der Modelltransformation Abbildung 4.3: Auszug aus der Essential MOF[OMGM06] Seite 33 EMOF eine Class ist und unter anderem ein ownedattribute namens name besitzt. Im UML-Metamodell können Metaklassen von anderen Metaklassen erben. Das findet sich auf der EMOF-Ebene durch die Meta-Metaassoziation superclass des Class-Elements wieder. Dadurch, dass sie mehrere Superklassen besitzen kann, ist die Mehrfachvererbung bereits auf Metamodellebene möglich. Mit dem Wissen über den Aufbau des Metamodells durch die EMOF, lässt sich somit ein einfacher Algorithmus (siehe Listing 4.2) für die Generierung von Prädikaten angeben, die das zum UML-Metamodell äquivalente Metamodell für Fakten einer Logikprogrammiersprache bildet. Eine Prädikaterstellung bedeutet hier, dass, wie im vorherigen Abschnitt beschrieben, Typen und Inferenzmodi definiert werden, die später in die Wissensbasis des Logikprogramms aufgenommen werden. Der Algorithmus arbeitet jedes Metamodellelement der UML sukzessive ab, indem er den Syntaxgraph des UML- 43

52 4 Ansatz 1 Für jede EMOF - Class x einer Metaklasse mache { 2 Erstelle das Prädikat x mit Stelligkeit Für jedes ownedatttribute a von x mache { 5 Erstelle das Prädikat a mit Stelligkeit 2 6 } 7 8 Für jede superclass super von x mache { 9 Erstelle eine Regel super (? class ) :- x(? class ). 10 } 11 } Listing 4.2: Einfacher Algorithmus, um die Prädikate für das Fakten-Metamodell zu generieren Metamodells traversiert, und erstellt für dieses Element ein einstelliges Prädikat (Zeile 1-2 in Listing 4.2), das es als ein bestimmtes Metamodellelement identifiziert, und weitere zweistellige Prädikate für jedes Metaattribut und jedes Metaassoziationsende, das es besitzt (Zeile 4-6 in Listing 4.2). Des Weiteren werden für das aktuell traversierte Element Regeln erzeugt, die die Vererbungsbeziehung zu seinen vererbenden Superklassen ausdrücken (Zeile 8-10 in Listing 4.2). Für die Parameter ist es jeweils wichtig, dass sie getypt 1 werden. Den Typen geben jeweils die Metaattribute, sowie Metaassoziationen an, da sie einen bestimmten Typen haben. Der Algorithmus generiert somit ein Modell, das alle Typen, Prädikate und Regeln enthält, die eine Abbildung des UML-Metamodells in einer Logiksprache sind. Es wird für die folgende Generierung der Fakten, die ein Modell repräsentieren, als Metamodell dienen, da es den Aufbau der Fakten beschreibt Generierung der Fakten Die Generierung der Fakten verläuft ähnlich zu der Generierung der Prädikate. Hier wird allerdings nicht der Syntaxgraph des UML-Metamodells traversiert, sondern der des Modells. Bei der Traversierung erhält jedes Element des Modells einmalig eine eindeutige Indizierung, die beispielsweise durch die Reihenfolge der Elemente 1 Es hat sich bei der Entwicklung des Werkzeugs herausgestellt, dass bei einer Typisierung der Parameter die Mehrfachvererbung innerhalb des UML-Metamodells von der Logiksprache TyRuBa nicht akzeptiert wird, weshalb alle Parameter vom Typ Object angelegt werden. 44

53 4.1 Konzeption der Modelltransformation bei der Traversierung festgelegt sein kann. Dabei erhält kein Element zwei Indizes. Diese eindeutige Indizierung ermöglicht es, Elementen als Fakt eine Eigenschaft zuzuweisen oder sie mit anderen Modellelementen in Verbindung zu setzen, ohne dass eine Mehrdeutigkeit entsteht. Die Generation verläuft so, dass nun für jedes Modellelement, das bei der Traversierung betrachtet wird, aus dem Prädikatenmodell diejenigen Prädikate gesucht werden müssen, die den Metaassoziationen und Metaattributen der Metaklasse des Modellelements entsprechen, damit die Eigenschaften des aktuellen Elements und seine Beziehungen zu anderen Elementen als Fakt ausgedrückt werden können. Es bieten sich zwei Varianten an, wie bei Erzeugung von Fakten verfahren werden kann. Die erste ist es, für das aktuelle Modellelement eine Abbildung zu generieren, die ihm die korrekten Prädikate zuweist, die für Fakten benötigt werden. Das hat allerdings den Nachteil, dass für Modellelemente, die eine gleiche Metaklasse haben, diese Abbildung stets neu erzeugt werden muss. Für große Modelle ist dieses Verfahren aus Performancegründen ungeeignet. Die zweite Variante ist es, vorab für jede Metaklasse, unabhängig, ob sie im Modell instanziert worden ist oder nicht, eine solche Abbildung zu schaffen. Dafür muss der abstrakte Syntaxgraph des UML-Metamodells traversiert werden, damit jede Metaklasse eine entsprechende Abbildung auf seine benötigten Prädikate erhält, um mit ihnen ihren Inhalt und ihre Beziehungen zu anderen Metaklassen als Fakt auszudrücken. Bei der Traversierung auf dem Modell kann nun über seine Metaklasse direkt auf die zuvor für diese Metaklasse generierte Abbildung zugegriffen und die Prädikate benutzt werden, die das Element als Fakten darstellen. Da dieses Abbildungsverzeichnis zwischen Metaklassen und ihren nötigen Prädikaten nur einmal erzeugt werden muss, ist diese Variante der Faktengeneration wesentlich performanter als die erste Variante. Sie ist für die Realisierung des Programms auch verwendet worden. Die Abbildung 4.4 zeigt ein minimales Beispiel für eine Klasse namens Kunde, die als Element der Wissensbasis transformiert werden soll. Dabei fokussiert das Beispiel wieder auf einen Teil des kompletten UML-Metamodells, damit die Komplexität zur Veranschaulichung nicht zu hoch wird. Die gezeigte Klasse besitzt ein Attribut mit dem Namen identifier. Die im UML-Metamodell beschreibenden Metaklassen sind Class, die die Klasse repräsentiert, Property, welches das Attribut der Klasse ist, zwei Generalizations, die jeweils von NamedElement erben, welche der Klasse und dem Attribut den Namen zuteilen. Des Weiteren wird durch die Metaassoziation ownedattribute angezeigt, dass das Attribut auch zu Klasse gehört. Die rechte Seite der Abbildung zeigt das zum UML-Metamodell äquivalente Prädikatenmodell, das hier auch nur auszugsweise, aber gleichermaßen zum 45

54 4 Ansatz Metamodell, dargestellt ist, aus dem nun die für eine Klasse relevanten Prädikate ermittelt werden. Der konkrete Inhalt für die Fakten kann nun aus dem Modell bezogen werden. Abbildung 4.4: Minimales Beispiel der Faktengenerierung 4.2 Konzeption von Regeln Dieser Abschnitt beschäftigt sich mit den Fragen, wie Regeln für eine Überprüfung auf eine strikte Schichtenarchitektur konzipiert werden können und wie die Ergebnisse darzustellen sind. 46

55 4.2 Konzeption von Regeln Überblick Ein Logikprogramm wertet eine Anfrage mit einer erfolgreichen Ableitung aus oder zeigt an, dass sie nicht abgeleitet werden konnte. Eine nicht erfolgreiche Ableitung des Inferenzalgorithmus bietet allerdings den Vorteil, dass zwischenzeitliche Variablenunifikationen als Lösung ausgegeben werden. Dies sind zwar gültige Lösungen, bei denen der Anfragensteller einen Erfolg als Rückmeldung erwarten würde, nichtsdestotrotz führt das Programm eine erschöpfende Tiefensuche durch, um alle Lösungen zu finden, bis es mit einem Fehlschlag abbricht, auch wenn TyRuBa dieses nicht meldet. Eine erschöpfende Suche bietet sich hervorragend an, um ein Modell nicht nur auf gültige oder ungültige Beziehungen zu testen, sondern diese auch angeben zu lassen. Eine Überprüfung soll nicht nur einem Test, ob ein Modell irgendwelche Anforderungen erfüllt, dienen, sondern dem Benutzer aktiv anzeigen, was an einem Modell stimmt oder nicht stimmt. In diesem Sinne ist es angebracht, eine Regel zu formulieren, die ausschließlich mit freien Parametern angefragt werden kann, damit diese mit gültigen Lösungen belegt werden können. Die Abbildung 1.1 hat bereits gezeigt, wie die Konsistenz zwischen Architekturund Designmodell überprüft werden soll. Der Weg einer Transformation von einem Modell zu Fakten einer Logikprogrammiersprache ist bereits geebnet. Die linke Seite dieser Abbildung bleibt noch offen, wie aus einem Architekturmodell entsprechend Regeln für die Logikprogrammiersprache zu definieren sind, mit denen sich Anfragen auf die Fakten stellen lassen. Dies ist allerdings nicht Gegenstand dieser Arbeit. Daher werden auf einer abstrakten Ebene Prädikate definiert, mit denen sich Fakten und Regeln erstellen lassen, die dennoch eine Überprüfung auf eine strikte Schichtenarchitektur gestatten Darstellung der Schichten In Kapitel 3 ist bereits erläutert worden, warum Pakete ein geeignetes Modellelement sind, um eine Schicht abstrakt zu beschreiben. Diese Pakete müssen nun als Schichten interpretiert in die Wissensbasis aufgenommen werden. Eine erste Idee ist es also, Schichten zu definieren und sie als Fakten darzustellen. Im Anschluss muss ein Prädikat definiert werden, welches ein Paket jeweils einer Schicht zuweist. Das Listing 4.3 zeigt eine Definition für das Prädikat, das eine Schicht beschreibt. Das Schichten-Prädikat ist einstellig gewählt, da es keiner weiteren Parameter bedarf, um eine Schicht zu definieren. Der Parameter stellt somit den Namen der 47

56 4 Ansatz 1 layer :: Object 2 MODES 3 (B) IS SEMIDET 4 (F) IS NONDET 5 END Listing 4.3: Definition einer Schicht Schicht dar. Die Modi sind jeweils semi-deterministisch gewählt, falls der Parameter gebunden ist, da eine gültige Lösung existiert oder nicht, und nicht-deterministisch, falls der Parameter frei ist, da es mehrere Lösungen für eine gültige Belegung der Variablen geben könnte. Das Schichten-Prädikat besitzt noch keinen Bezug zu den Schicht-Paketen des Modells. Daher muss nun auf geeignete Weise ein Paket einer Schicht zugewiesen werden. Hierfür bieten sich mehrere Möglichkeiten an. Ein Paket, das eine Schicht repräsentieren soll, besitzt als Fakt in der Wissensbasis einen eindeutigen Index, der dieses Paket identifiziert. Allerdings kann sich dieser bei der kleinsten Änderung im Modell verändern und der Softwareentwickler hat nicht zwingend Zugang zu den Fakten, um den Index nachzuschlagen. Eine Identifizierung anhand des Paketnamens klingt intuitiv, ist aber ebenso keine gute Lösung. Der Paketname ist dem Softwareentwickler zwar bekannt, allerdings ist dieser nicht unbedingt eindeutig. Ein Modell, wie beispielsweise CoCoME besitzt viele Pakete mit dem Namen impl. Würde nun impl als Schicht angenommen werden, so würden alle gleichnamigen Pakete ebenso zu dieser Schicht gehören, da sie denselben Namen besitzen. Die nächste Möglichkeit, die sich bietet und auch die Lösung ist, ist es, über den qualifizierenden Namen des Paketes, es als Schicht zu identifizieren, siehe hierzu [OMGS07] S. 98ff. Das Prädikat ist zweistellig zu wählen, da es ausdrücken soll, welches Paket zu welcher Schicht gehört und umgekehrt. Das Listing 4.4 zeigt die Definition des Prädikats packageislayer. Da durch Fakten explizit festgelegt wird, welches Paket zu welcher Schicht gehört, müsste bei der Modus-Definition eigentlich nur der erste Fall - beide Parameter gebunden - betrachtet werden. Vollständigkeitshalber sind aber alle anderen Modi auch angegeben, damit auch Anfragen erlaubt sind, die die Pakete einer Schicht ermitteln. Der nicht-deterministische Fall für die Inferenz erklärt sich dadurch, dass mehrere Pakete einer Schicht zugewiesen werden können. Falls also der erste Parameter frei ist, so wird vom Inferenzalgorithmus die nächste Lösung ermittelt. Im CoCoME sollen die drei Schichten GUI, Application und Data betrachtet wer- 48

57 4.2 Konzeption von Regeln 1 packageislayer :: Object, Object 2 MODES 3 (B,B) IS SEMIDET 4 (B,F) IS SEMIDET 5 (F,B) IS NONDET 6 (F,F) IS NONDET 7 END Listing 4.4: Definition einer Beziehung zwischen Paketen und Schichten den. Das Listing 4.5 zeigt die Fakten zur Festlegung der Schichten und der Zuweisung von Paketen zu Schichten. 1 layer (" application "). 2 layer (" gui "). 3 layer (" data "). 4 packageislayer ( 5 " Cocome :: org :: cocome :: 6 tradingsystem :: inventory :: gui "," gui "). 7 packageislayer ( 8 " Ccocome :: org :: cocome :: 9 tradingsystem :: inventory :: application "," application "). 10 packageislayer ( 11 " Cocome :: org :: cocome :: 12 tradingsystem :: inventory :: data "," data "). Listing 4.5: Fakten für die Schichtendefinition im CoCoME Die ersten drei Fakten definieren die Schichten des Informationssystems. Der Fakt layer("gui") definiert eine Schicht, die gui heißt. Im nächsten Schritt werden Fakten definiert, die den definierten Schichten Pakete über deren qualifizierenden Namen zuweisen, beispielsweise packageislayer("cocome::org::cocome:: tradingsystem::inventory::gui","gui"). Durch die Zuweisung eines Pakets zu einer Schicht werden implizit auch alle Unterpakete des Schichtenpakets dieser Schicht zugeordnet. Über das Prädikat packageislayer können außerdem weitere Pakete derselben Schicht zugewiesen werden. Es gilt nicht, dass nur ein Paket eine 49

58 4 Ansatz Schicht darstellt, sondern eine Schicht durch mehrere Pakete repräsentiert werden kann Entwicklung einer Schichtenregel Die Darstellung der Schichten als Fakten ist bereits eine wichtige Grundlage. Für eine Überprüfung auf eine strikte Schichtenarchitektur muss noch definiert werden, was eine Abhängigkeitsbeziehung zwischen Schichten bedeutet und welche davon erlaubt sind. Schichten haben dann eine Abhängigkeit untereinander, wenn ihre repräsentierenden Pakete eine Beziehung eingehen. Diese Beziehungen können unterschiedlich aufgebaut sein. Zum einen können die Pakete einer Schicht selber von einem Paket einer anderen Schicht abhängen und zum anderen kann ein Element innerhalb des Pakets eine Abhängigkeit zu einem Paket oder Element einer anderen Schicht haben. Um eine Abhängigkeitsbeziehung als Fakt in der Wissensbasis zu verallgemeinern, wird ein zweistelliges Prädikat definiert, das eine erlaubte Abhängigkeitsbeziehung zwischen je zwei Schichten anzeigt, wie es das Architekturmodell vorsieht. Dabei müssen bei der Entwicklung einer auf eine strikte Architektur überprüfenden Regel die beschriebenen Fälle von unterschiedlichen Beziehungen behandelt werden. Das Listing 4.6 zeigt das zweistellige Prädikat alloweddependency, welches erlaubte Abhängigkeiten von einer Schicht (erster Parameter) zu einer Schicht (zweiter Parameter) definiert. 1 alloweddependency :: Object, Object 2 MODES 3 (B,B) IS SEMIDET 4 (B,F) IS NONDET 5 (F,B) IS NONDET 6 (F,F) IS NONDET 7 END Listing 4.6: Prädikatdefinition, die erlaubte Beziehungen zwischen Schichten ausdrückt Nur der Modus (B,B) ist semi-deterministisch gewählt, weil eindeutig festgelegt ist, welche Schicht von welcher anderen abhängt. Die anderen Modi sind nicht- 50

59 4.2 Konzeption von Regeln deterministisch zu wählen, da eine Schicht von mehreren abhängen kann oder mehrere Schichten von einer abhängen können. Auch bei diesem Prädikat muss der Softwareentwickler explizit als Fakt angeben, welche Beziehungen zwischen den Schichten erlaubt sind. Im Falle von CoCoME würden die Fakten wie in Listing 4.7 gewählt werden, um eine Abhängigkeit der Applikationsschicht von der Datenschicht und der GUI-Schicht von der Applikationsschicht anzuzeigen. 1 alloweddependency (" gui "," application "). 2 alloweddependency (" application "," data "). Listing 4.7: Fakten für erlaubte Schichtabhängikeiten Die bisher beschriebenen Prädikate muss der Entwickler als Fakten angeben, bevor er eine Anfrage an das Logikprogramm starten kann, da eine automatische Generation dieser Prädikate mit den zugehörigen Fakten noch nicht existert. Das in dieser Arbeit entwickelte Werkzeug wird dem Softwareentwickler eine einfache Möglichkeit bieten, diese Fakten in die Wissensbasis einzufügen. Als letztes muss eine Regel entworfen werden, die ein Modell dahingehend überprüft, ob es die Anforderungen der Schichtenarchitektur erfüllt, wie sie durch die bereits genannten Fakten definiert und in Abhängigkeit gebracht worden sind. Sie wird im Werkzeug stets in die Wissensbasis aufgenommen und muss vom Entwickler nicht gewartet werden. Ziel der Regel für eine automatische Überprüfung soll es sein, alle möglichen Beziehungen, die zwischen Schichten existieren und eine ungültige Abhängigkeitsbeziehung erfüllen, herauszufinden und dem Softwareentwickler anzuzeigen. Es gilt hier die Aufgabe zu lösen, was genau eine Beziehung zwischen Schichten ausdrückt. Es ist bereits allgemein beschrieben worden, dass solche Beziehungen zwischen bestimmten Elementen existieren, aber nicht, wie diese konkret aussehen. Dies wird im folgenden näher diskutiert. Modellelemente der UML haben allgemein dann eine Beziehung untereinander, wenn sie voneinander abhängen, indem sie den Typ, die Funktionen oder gekapselte Elemente des gegenüberliegenden Modellelements benutzen. Die UML drückt dies etwas spezieller durch die MetaklasseRelationship aus, die zwei Elemente bidirektional in Beziehung setzt. Die Abbildung 4.5 zeigt einen Auszug aus dem UML- Metamodell, der unter anderem die Metaklasse Relationship zeigt. Sie besitzt eine Metaassoziation relatedelement, welche jeweils mehrere Elemente untereinander in 51

60 4 Ansatz Beziehung setzen kann. Abbildung 4.5: Auszug aus dem UML-Metamodell [OMGS07] Seite 25 Assoziationen sind die einzigen Elemente in der Modellierung, mit denen sich bidirektionale Abhängigkeitsbeziehungen beschreiben lassen, da sie direkt von Relationship erben, wie die Abbildung 4.6 zeigt. Eine Assoziation hat als Enden jeweils ein Property, das einen Typen haben kann oder nicht. Das Property selber kann dabei entweder von einer Class über die Metaassoziation ownedattribute oder von der Assoziation über ownedend besessen werden. Eine Assoziation bietet auch die Möglichkeit, nicht nur bidirektionale Abhängigkeiten auszudrücken, sondern auch unidirektionale, sogenannte navigierbare Assoziationen. An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends; otherwise, the association is not navigable from the opposite ends. [OMGS07] Seite

61 4.2 Konzeption von Regeln Für eine Schichtenüberprüfung muss bei Assoziationen ein besonderes Augenmerk geworfen werden. So wie eine bidirektionale Abhängigkeit zwischen Modellelementen verschiedener Schichten besteht, würden die Anforderungen an die Schichtenarchitektur durch die bereits definierten Fakten verletzt werden. Daher müssen im weiteren auch die Assoziationen in Betracht gezogen werden, die nicht nur ein einziges navigierbares Ende besitzen, sondern auch überprüft werden, ob die Navigationsrichtung der Abhängigkeitsbeziehung widerspricht. Abbildung 4.6: Auszug aus dem UML-Metamodell [OMGS07] Seite 32 Die Modellierung einer Assoziation mit nur einem navigierbaren Ende in einer abstrakten Syntax ist innerhalb des UML-Metamodells nicht eindeutig bestimmt, sodass sich zwei Fälle ergeben, die in Abbildung 4.7 aufgezeigt sind. 53

62 4 Ansatz Abbildung 4.7: Gerichtete Assoziationen können auf zwei Arten im Metamodell modelliert werden Die Abbildung zeigt in konkreter Syntax eine Klasse A, die über eine gerichtete Assoziation die Klasse B referenziert. Diese Beziehung kann in abstrakter Syntax auf zwei Arten modelliert werden: Fall 1: Das Property attb wird von der Klasse A definiert und ist bei der Assoziation als ein memberend definiert. Dies drückt die Navigierbarkeit von Klasse A nach Klasse B aus. Da eine Assoziation noch ein zweites memberend benötigt, muss ein weiteres Property definiert werden. Dieses gehört allerdings zur Assoziation selbst, als ownedend, denn wenn es von einer Klasse besessen werden würde, gäbe es wieder eine Navigierbarkeit dadurch, dass die Klasse eine andere referenziert. Das zu der Assoziation gehörige Property kann einen Typen besitzen, wobei hier darauf zu achten ist, dass der Typ keine Abhängigkeitsverletzung erzeugt. Wäre es getypt würde es unter anderem 54

63 4.2 Konzeption von Regeln wieder ein anderes Element navigierbar referenzieren. Fall 2: Die Assoziation definiert beide Properties. Eins wird als navigableownedend angelegt, das andere als ownedend, so wie im ersten Fall. Das navigierbare Ende ist ein TypedElement, das den Typen der Klasse B trägt. Beide Fälle gilt es bei dem Entwurf einer Regel zu beachten. Die Metaklasse DirectedRelationship ist eine Spezialisierung von Relationship, wie in Abbildung 4.5 ebenfalls zu erkennen ist. Sie drückt explizit eine gerichtete Beziehung zwischen zwei Elementen aus. Hierunter fallen Paketimporte, Generalisierungen, Paketmerges, Interfacerealisierungen und -benutzungen und weitere. Die Metaassoziationen source und target referenzieren dabei jeweils paarweise, welches source-modellelement von welchem target-element abhängt. Die letzte Art einer Beziehung, die zwischen Elementen eingegangen werden kann, drückt sich nicht explizit durch eine Metaklasse aus, die eine Beziehung repräsentiert. Sie wird implizit durch den Sachverhalt festgelegt, dass ein Modellelement den Typen eines anderen Modellelements benutzt. Dieser Fall tritt bei der Metaklasse Property und Parameter auf. Wie die Abbildung 4.8 zeigt, erben beide Metaklassen von TypedElement, die ein typisiertes Modellelement beschreiben. Der Typ dieses Elements wird durch die Metaassoziation type bestimmt. Er hat die Multiplizität von 0..1, was bedeutet, dass ein Element einen Typen haben kann oder nicht. Davon abhängig kann dieses Element somit eine Beziehung zu einem anderen Modellelement eingehen. Unter Beachtung der beiden Sonderfälle der Assoziationen treten also vier Fälle für mögliche Abhängigkeiten zwischen Modellelementen und somit auch für Schichten auf. Die zu entwickelnde Regel muss also nun diejenigen Elemente finden, welche eine vorgegebene Abhängigkeitsbeziehung erfüllen. Diese kann als ein dreistelliges Prädikat angenommen werden, wie Listing 4.8. Der erste Parameter gibt dabei ein Modellelement an, das Abhängigkeitsbeziehungen erfüllt, die durch die nächsten beiden Parameter angegeben werden. Sie stellen jeweils eine Quell- und eine Zielschicht dar. Die Regel getillegalreferences(?element,?sourcelayer,? targetlayer) ist in Listing 4.8 gezeigt und dann erfüllt, wenn es eine Belegung für Schichten?sourceLayer und?targetlayer gibt, die eine ungültige Abhängigkeitsbeziehung haben und es eine Belegung der Variablen?element gibt, die ein Modellelement darstellt, welches eine Beziehung zwischen diesen Schichten ausdrückt. Dieses Prädikat besitzt als Inferenzmodi bis auf den Fall, dass alle Para- 55

64 4 Ansatz Abbildung 4.8: Zusammenschnitt aus dem UML-Metamodell [OMGS07] meter gebunden sind, nicht-deterministische Modi, da erschöpfend gesucht werden soll. Im Fall aller gebundenen Parameter muss nur überprüft werden, ob es für die konkrete Belegung ein Ergebnis gibt oder nicht. Diese Regel ist jedoch nicht ohne weitere Hilfsregeln zu realisieren, die Teillösungen generieren, die für die Abarbeitung der getillegalreferences-regel benötigt werden. Die Regel notalloweddependency(?sourcelayer,?targetlayer) in Listing 4.9 erfüllt den ersten Teilpunkt der Schichtenregel und generiert die Teillösung, die die 1 getillegalreferences (? illegalelement,? fromlayer,? tolayer ) :- 2 notalloweddependency (? fromlayer,? tolayer ), 3 al lref eren ces Betw een Laye rs (? illegalelement,? fromlayer,? tolayer ). Listing 4.8: Die Regel getillegalreferences 56

65 4.2 Konzeption von Regeln Variablen?sourceLayer und?targetlayer mit einer ungültigen Abhängigkeitsbeziehung unifiziert. Die Regel funktioniert so, dass sie erschöpfend die Variablen zuerst mit einer in den Fakten angegebenen gültigen Schicht belegt. Die Abhängigkeitsbeziehung für die beiden gefundenen Schichten ist dann ungültig, wenn beide Schichten ungleich sind und sie eine nicht gültige Beziehung zueinander eingehen. Alle Modi des Prädikats, die mindestens einen freien Parameter beinhalten, sind nicht-deterministisch, da mehrere Schichten von einer abhängen können oder eine Schicht von mehreren Schichten abhängen kann. 1 notalloweddependency (? one,? two ):- 2 layer (? one ),layer (? two ), 3 NOT ( alloweddependency (? one,? two )), 4 NOT ( equals (? one,? two )). Listing 4.9: Die Hilfsregel getnotalloweddependency Die zweite Hilfsregel ist allreferencesbetweenlayers(?element,?sourcelayer,?targetlayer), die in den folgenden Listings näher erläutert werden wird. Diese Regel ist dann erfüllt, wenn ein Element existiert, welches die Abhängigkeitsbeziehung der gegebenen Schichten erfüllt. Dabei gilt als Einschränkung für das Element, dass es sich um eine Relationship, eine DirectedRelationship oder ein Typed- Element handelt, wie es bereits diskutiert worden ist. Somit teilt sich diese Regel in folgende vier Teile auf, um jede Abhängigkeitsart zu behandeln: DirectedRelationship: Eine DirectedRelationship besitzt ein source- und ein target-element, wie Abbildung 4.6 bereits gezeigt hat. Sie können angesprochen und darauf überprüft werden, ob diese Elemente jeweils in der Quell- bzw. Zielschicht liegen. Das Listing 4.10 zeigt die Regel, die dann wahr wird, wenn es ein Element?ref gibt, das eine DirectedRelationship ist und für das ein source-element existiert, das in der Quellschicht liegt und für das ein target- Element innerhalb der Zielschicht existiert. Assoziation mit navigableownedend: Falls es sich bei dem zu ermittelnden Element nicht um eine DirectedReationship handelt, so wird überprüft, ob eine Assoziation mit einem navigalbeownedend die Abhängigkeitsbeziehung erfüllt. Für das Attribut des navigierbaren Endes gilt, dass sein Typ innerhalb 57

66 4 Ansatz 1 allreferencesbetweenlayers (? ref,? fromlayer,? tolayer ):- 2 DirectedRelationship (? ref ), 3 ( EXISTS? source : 4 directedrelationship_source (? ref,? source ), 5 layer4element (? source,? fromlayer ), 6 ( EXISTS? target : 7 directedrelationship_target (? ref,? target ), 8 layer4element (? target,? tolayer ))), 9 layer (? fromlayer ), 10 layer (? tolayer ). Listing 4.10: allreferencesbetweenlayers für DirectedRelationships der Zielschicht definiert sein muss und für das Attribut des anderen Assoziationsende gilt, dass sein Typ in der Quellschicht deklartiert sein muss, damit es den Anforderungen der Überprüfung gerecht wird. Die Regel im Listing 4.11 ist somit dann erfüllt, wenn es ein Element?ref gibt, das eine Assoziation mit navigierbarem Ende ist, sodass für dieses Ende ein Typ existiert, der in der Zielschicht definiert ist und ein weiterer Typ existiert, mit dem das andere Assoziationsende typisiert ist, der in der Quellschicht definiert ist. 1 allreferencesbetweenlayers (? ref,? fromlayer,? tolayer ):- 2 association_navigableownedend (? ref,? navownedend ), 3 ( EXISTS?type,? type2 : 4 typedelement_type (? navownedend,? type ), 5 association_ownedend (? ref,? owned ), 6 typedelement_type (? owned,? type2 ), 7 NOT ( equals (? owned,? navownedend )), 8 layer4element (? type2,? fromlayer ) 9 layer4element (? type,? tolayer )), 10 layer (? fromlayer ),layer (? tolayer ). Listing 4.11: allreferencesbetweenlayers für Associations mit navigierbarem Ende Assoziation mit Attributen bei den Klassen: Falls es sich bei dem gesuchten Element um eine Assoziation handelt, bei der ein memberend bei einer Klasse 58

67 4.2 Konzeption von Regeln liegt, so muss hier überprüft werden, ob der Typ des Attributs ebenfalls in der Zielschicht definiert ist, während das Attribut selber in der Quellschicht deklariert ist. Die Regel in Listing 4.12 wird also dann wahr, wenn es ein Element?ref gibt, das eine Assoziation ist und einen Property als memberend hat, das in der Quellschicht und dessen Typ in der Zielschicht definiert ist. 1 allreferencesbetweenlayers (? ref,? fromlayer,? tolayer ):- 2 Property (? prop ), 3 association_memberend (? ref,? prop ), 4 layer4element (? prop,? fromlayer ), 5 typedelement_type (? prop,? type ), 6 layer4element (? type,? tolayer ). Listing 4.12: allreferencesbetweenlayers für Associations mit Attributen bei den Klassen TypedElement: Ein TypedElement ist innerhalb der UML keine Relationship. Daher wird für diesen Fall das Element gesucht, welches ein typisiertes Element ist und einen Typen besitzt, der in einem anderen Schichtenpaket definiert ist. Somit wird die Regel in Listing 4.13 dann erfüllt, wenn ein Element?ref existiert, das ein TypedElement ist, welches in der Quellschicht definiert ist und einen Typen hat, der in der Zielschicht deklariert ist. 1 allreferencesbetweenlayers (? ref,? fromlayer,? tolayer ):- 2 typedelement_type (? para,? type ), 3 layer4element (? para,? fromlayer ), 4 layer4element (? type,? tolayer ), 5 equals (? ref,? para ). Listing 4.13: allreferencesbetweenlayers für Parameter Die verwendete Hilfsregel layer4element(?element,?layer) gibt die Schicht zurück, die das Element enthält. Die Regel ermittelt rekursiv den Besitzer des Elements und testet, ob der Besitzer einer Schicht zugeordnet ist, wenn nicht das Element selbst bereits die Schicht repräsentiert. Sie wird von der Schichten-Regel 59

68 4 Ansatz stets im (B,B)-Modus aufgerufen und dient daher dem Test, ob ein bestimmtes Element in einer bestimmten Schicht enthalten ist. Die erschöpfende Suche gibt nun für jedes Element, das den obigen Anforderungen genügt als mögliches Ergebnis aus. Der Benutzer kann so ersehen, welche Elemente eine ungültige Abhängigkeitsbeziehung eingehen. 4.3 Zusammenfassung Dieses Kapitel hat die Konzepte einer Metamodell- und Modelltransformation in Typen, Regeln, Prädikate und Fakten beschrieben, worauf nun das zu entwickelnde Werkzeug aufbauen kann. Es hat erläutert, wie Prädikate entsprechend zu ihren (Meta-) Modellelementen zu definieren sind und automatisch generiert werden können, damit sie für die Erzeugung von Fakten verwendet werden können. Des Weiteren sind Regeln und Prädikate für die Überprüfung einer strikten Schichtenarchitektur konzipiert worden, welche allerdings noch vom Benutzer manuell zu entwickeln sind. Es wird angestrebt, diese Benutzerinteraktion herauszunehmen und die Erstellung solcher Regeln und Prädikate zu automatisieren, wie es in Kapitel 7 als weiterführende Arbeit beschrieben wird. Bei dem Entwurf der Regeln ist dabei darauf zu achten, dass sie exakt die strukturellen Eigenschaften beschreiben, die die Architektur vorgegeben hat, da eine automatische Überprüfung mit der Logikprogrammiersprache auf diesen Regeln arbeitet. Würden die Regeln abweichen, müssten dementsprechend auch die Ergebnisse der Anfrage anders interpretiert werden. 60

69 5 Design und Implementierung Dieses Kapitel beschäftigt sich mit dem Design und der Realisierung der Konzepte aus dem vorangegangenen Kapitel als ein Werkzeug für den Softwareentwickler, das verschiedene Anfragen auf ein Modell nach bestimmten Eigenschaften ermöglicht. Da das Programm auf dem Eclipse Modeling Framework beruht, welches auch die Modellierung mit UML ermöglicht, bietet es sich an, das Werkzeug als Plugin für die weit verbreitete Entwicklungsplattform Eclipse zu integrieren. Das Kapitel beschreibt in mehreren Abschnitten die einzelnen Schritte der Pluginrealisierung und wie sich dort jeweils die Konzepte aus Kapitel 4 wiederfinden. Das Plugin unterteilt sich in mehrere Teilsysteme, die unabhängig voneinander verschiedene Aufgaben, wie beispielsweise die Prädikatengenerierung, die Faktengenerierung und den Anfragemechanismus, erfüllen. Diese Teilsysteme werden in den nächsten Abschnitten erläutert, das Design erklärt und auf Implementierungsdetails eingegangen. 5.1 Designüberblick Nach der Konzeption einer Modelltransformation in Fakten ergeben sich vorerst zwei Teilsysteme, die diese Transformation realisieren. Das erste Teilsystem ist die Metamodel to Logic Transformation (MELT), das als Eingabe ein Metamodell erhält, aus dem es ein Zwischenmodell generiert, das alle Prädikat-, Typen- und Regeldefinitionen des Metamodells hält. Dies entspricht den Konzepten aus dem Abschnitt Generierung von Prädikaten auf Seite 41ff. Das zweite Teilsystem Model to Logic Transformation (MLT) erhält als Eingabe sowohl das Zwischenmodell als auch das Modell, das es zu transformieren gilt. Das zweite System verknüpft nun die Informationen aus den Prädikat-, Regel- und Typdefinitionen mit entsprechenden Informationen aus dem Modell, um Fakten zu erstellen, wie es im Abschnitt Generierung der Fakten auf Seite 44ff konzeptioniert worden ist. 61

70 5 Design und Implementierung Damit ein Softwareentwickler diese beiden Systeme für eine Modellüberprüfung auf bestimmte Eigenschaften verwenden kann, werden zwei weitere Teilsysteme benötigt. Zum einen muss ein Teilsystem programmiert werden, welches die Logikprogrammiersprache TyRuBa zur Anfrageausführung an das Plugin bindet und zum anderen muss ein Teilsystem eine Benutzerschnittstelle realisieren, die dem Softwareentwickler die Möglichkeit bietet, Modelle auf die Eigenschaften überprüfen zu können, die er als Anfrage formuliert an das System weitergibt. Es ergibt sich somit das in Abbildung 5.1 gezeigte Komponentendiagramm der einzelnen Teilsysteme. Abbildung 5.1: Kommunikation und Funktion der Teilsysteme Das Zusammenspiel der einzelnen Teilsysteme wird durch das Aktivitätsdiagramm in Abbildung 5.2 beschrieben und zeigt den Ablauf der Modell zu Fakten Transformation mit anschließender Auswertung einer Benutzeranfrage an die Fakten des Modells. Das UML-Metamodell wird als Modelldatei von dem Teilsystem MELT benutzt, welches Prädikat-, Typ- und Regeldefinitionen in einem zielsprachenunabhängigen Zwischenmodell erstellt und dem Teilsystem MLT durch eine geeignete Schnittstelle bereit stellt. Die Definitionen müssen allerdings auch zielsprachenspezifisch in Dateien gespeichert werden, damit sie in die Wissensbasis von TyRu- Ba aufgenommen werden können. Hierfür nutzt MELT die Frontend-Schnittstelle von TyRuBa. Ansonsten könnte das Logikprogramm nicht auf die Definitionen 62

71 5.2 Teilsystem Metamodel to Logic Transformation Abbildung 5.2: Allgemeiner Ablauf einer Modell zu Fakten Transformation mit anschließender Auswertung aller Prädikate, Regeln und Typen zurückgreifen. MLT nutzt diese Definitionen des Zwischenmodells zusammen mit einem UML-Modell, um Fakten zu erzeugen, die an das Logikprogramm ebenfalls über die Frontend-Schnittstelle weitergereicht werden. Auf dieser Faktenbasis kann TyRuBa nun Benutzeranfragen ableiten und das Modell auf bestimmte Eigenschaften überprüft werden. Alle Teilsysteme werden als zusammenspielendes Gesamtsystem in Eclipse als Plugin integriert. 5.2 Teilsystem Metamodel to Logic Transformation MELT ist das Teilsystem, das das Metamodell des zu transformierenden Modells in ein von der Ziellogiksprache unabhängiges Zwischenmodell transformiert und dieses Zwischenmodell zielsprachenspezifisch in eine Datei ausgibt, wie es das Aktivitätsdiagramm in Abbildung 5.3 als Verfeinerung der Aktion MELT ausführen aus Abbildung 5.2 zeigt. Bei dem Zwischenmodell handelt sich um das MELT Intermediate Object Model, kurz MIOModell, welches die Elemente des Metamodells und ihre Beziehungen untereinander in Typen, Regeln und Prädikaten wie konzeptioniert allgemein ausdrückt. Die folgenden Abschnitte gehen auf das Design dieses Teilprogramms sowie des Zwischenmodells ein und erläutern Implementierungsdetails. 63

72 5 Design und Implementierung Abbildung 5.3: Transformationsablauf von MELT Design Das Teilsystem lässt sich in vier Funktionsbereiche unterteilen, die jeder eine bestimmte Teilaufgabe bei der Erzeugung des Zwischenmodells haben. Die Abbildung 5.4 zeigt ein grobes Design des Teilsystems mit den vier Paketen commandline, mio, miogenerator und backend, die jeweils einen Funktionsbereich darstellen. Paket commandline Es kapselt Klassen, die vom Benutzer angestoßen werden, um ein gegebenes Metamodell in ein zielsprachenunabhängiges Zwischenmodell zu transformieren und die dortigen Definitionen von Regeln, Prädikaten und Typen zielsprachenspezifisch in einer Datei auszugeben. Die Hauptklasse ist hier MeltT, die diese Transformation für TyRuBa als Zielsprache durchführen soll, in dem sie ein entsprechendes Backend für die Generation der Typen, Prädikate und Regeln benutzt. Paket mio Das Paket enthält die Klassen, die die Sprachelemente einer Logiksprache als ein Zwischenmodell darstellen. Die Eigenschaften von Metaklassen, -attributen und -assoziationen werden durch diese Elemente innerhalb der Wissensbasis ausgedrückt. Das Klassendiagramm (Abb. 5.4) zeigt mit der Klasse MIOModel nur einen Ausschnitt des gesamten Zwischenmodells. Daher wird mit der Abbildung 5.5 der 64

73 5.2 Teilsystem Metamodel to Logic Transformation Abbildung 5.4: Grobes Design des Teilsystems MELT Aufbau des kompletten MIOModells mit entsprechenden Klassen, die die Sprachelemente einer Logiksprache, wie Prädikate, Typ und Regel, darstellen, gezeigt. Die Klasse Type definiert einen Typen für ein Metamodellelement, der einen Namen und seine jeweils erbenden und vererbenden Typen kennt. Damit ein Prädikat für das Zwischenmodell vollständig definiert werden kann, muss für ein Prädikat sein Name, seine Stelligkeit und die Typen seiner Parameter gesichert werden. Dieses leistet die Klasse Predicate, die hierfür entsprechende Attribute definiert. Sie ist zudem noch mit der Klasse GenerationSourceInformation assoziiert, welche zu einem Prädikat zusätzliche Informationen speichert. Solche sind jeweils Referenzen auf die Metamodellelemente, die das Prädikat erzeugt haben und Informationen über die Multiplizität des Elements, welche Aufschluss über die Wahl der Inferenzmodi geben. Der Name für ein Prädikat ist für eine Metaklasse der Name der Metaklasse selbst und für Metaattribute und -assoziationen ein Name, der sich 65

74 5 Design und Implementierung Abbildung 5.5: Das MIOModell und seine MIOElemente aus dem Namen der Metaklasse, die dieses Attribut beziehungsweise Assoziation definiert, einem eindeutigen Trennungszeichen _ und dem Namen der Metaassoziation oder des Metaattributs zusammensetzt. Somit besitzt das Prädikat und später auch der Fakt einen intuitiv klingenden Namen und das Auffinden von ihnen wird erleichtert, wenn das angesprochene Abbildungsverzeichnis von Seite 45 erzeugt werden muss. Die Klasse Rule repräsentiert eine Regel, die aus einem Regelkopf und einem Regelrumpf besteht. Kopf und Rumpf einer Regel äußern sich im Modell durch eine Assoziation zu der Klasse AtomicPredicateExpression, die den Regelkopf darstellt und eine Assoziation zu der Klasse AbstractExpression, die den Regelrumpf repräsentiert. Eine AbstractExpression ist eine Verallgemeinerung und wird durch die Klassen VariableExpression und ConstantExpression weiter verfeinert. Sie drücken explizit aus, ob es sich beim Regelrumpf um einen variablen oder konstanten Ausdruck handelt. Die Abbildung 5.5 zeigt weiterhin noch das Interface MIOElement, das von verschiedenen Elementen des MIOModells implementiert wird. Es spielt bei der Transformation des Zwischenmodells in logiksprachenspezifischen Code eine entscheidende Rolle. 66

75 5.2 Teilsystem Metamodel to Logic Transformation Paket miogenerator Das Paket miogenerator enthält die Klassen, die die Funktion der Erzeugung des Zwischenmodells ausführen. Hierfür überführt der Generator die Elemente des UML-Metamodells, ihre Eigenschaften und Beziehungen in Sprachelemente einer Logiksprache, die durch das MIOModell definiert sind. Paket backend Das Paket backend definiert allgemein ein Backend, das der Benutzer implementieren muss, um die Ausgabe des Zwischenmodells in eine bestimmte Syntax der Zielsprache anzupassen. An dieser Stelle wird das Designpattern Factory verwendet, um eine Integration unterschiedlicher Backends auf verschiedene Ziellogiksprachen zu erleichtern, weil das zugrunde liegende System nicht an verschiedene Backends angepasst werden muss. Das System nutzt für die Transformation in Sourcecode das allgemeine Interface Backend. Dieses Interface erbt von MIOVisitor und bildet zusammen mit dem im mio-paket definierten MIOElement das Visitor-Designmuster, welches im folgenden Abschnitt erläutert wird, weil es für den Transformationsprozess verwendet wird. Innerhalb des backend-pakets befindet sich weiterhin das Interface TargetLanguageGenerator, welches mit Hilfe des implementierten Backends den Sourcecode der Ziellogiksprache zu dem MIOModell generiert. Das Visitor-Pattern Das Visitor-Pattern ist ein Designmuster, bei dem Methoden, die auf Elementen einer hierarchischen Klassenstruktur ausgeführt werden, in eine Klasse auslagert werden. Das bietet den Vorteil, dass im Falle der Hinzunahme einer Methode für diese Struktur nicht die gesamte Objektstruktur angepasst werden muss [GHJV95] (Seite 331ff), sondern nur Änderungen in der neuen Klasse vorgenommen werden müssen. Die Hinzunahme der neue Methode zieht sich bei einer Klassenhierarchie durch alle Klassen, wobei eine neue Methode für manche Klassen irrelevant ist. Die Abbildung 5.6 zeigt allgemein die Struktur des Visitor-Patterns. 67

76 5 Design und Implementierung Abbildung 5.6: Allgemeiner Aufbau des Visitor-Patterns Das Interface Besucher enthält alle visit-methode besuchbarer Elemente. Es wird von der Klasse KonkreterBesucher implementiert, die außerdem die Klasse Objektstruktur assoziiert, die Objekte des Interfaces Besuchbar aggregiert. Ein besuchbares Element implementiert, wie die Abbildung zeigt, ein Besuchbar- Interface und muss eine accept-methode implementieren, die einen bestimmten Visitor akzeptiert. Eine konkrete Besucher-Klasse kann auf so einem Element die accept-methode aufrufen. Wird die Besucher-Klasse als gültiger Visitor von einem Element angenommen, so wird auf ihr die visit-methode für dieses Element aufgerufen. Das Pattern wird für dieses Teilsystem verwendet, da es für den Erzeugungsprozess des Quellcodes zum korrespondierenden Zwischenmodell verwendet wird. Es ist eine Aufgabe des Teilsystems, jedes Element des MIOModells syntaktisch korrekt in eine TyRuBa-Sourcedatei auszugeben. Daher ermöglicht dieses Pattern, dass auch jedes im MIOModell existente Element besucht wird, damit für dieses entsprechender Code generiert werden kann. Das geschieht eben durch den Aufruf der visit-methode auf dem MIOModell. Der konkrete Visitor ist im Designmodell das vom Benutzer implementierte Backend, das alle visit-methoden für jedes Element des Zwichenmodells enthält, weil es von MIOVisitor erbt. Alle besuchbaren Elemente der Objektstruktur, also alle MIOModellelemente, implementieren das Interface MIOElement, das die Elemente einen bestimmten Besucher akzeptieren lässt. 68

77 5.2 Teilsystem Metamodel to Logic Transformation Implementierung Die Hauptklasse MeltT implementiert die einzelnen Transformationsschritte. Als erstes wird aus dem UML-Metamodell durch den MIOGenerator das MIOModell generiert. Über die EMF-API kann eine entsprechende Ecore-Datei, die das UML- Metamodell in einem XMI-Format [OMGX07] hält, geladen und die Modellelemente fortan als Java-Objekte benutzt werden. Ecore ist im EMF eine Implementation der EMOF, die zur Spezifikation von Metamodellen benötigt wird. Abbildung 5.7: Das Ecoremodell als die Implementierung der EMOF mit der für die Generierung wichtigen Meta-Metaklassen, -attributen und -assoziationen 69

78 5 Design und Implementierung Die Abbildung 5.7 zeigt das Ecoremodell und fokussiert dabei auf den relevanten Ausschnitt, der die Metaklassen, -attribute und -assoziationen des UML-Metamodells definiert. In Anlehnung an den Algorithmus 4.2 auf Seite 44 wird durch die API nun genau festgelegt, wie eine Metaklasse definiert ist, und wie ihre definierten Metaattribute und -assoziationen ermittelt werden können. Wird nun über jede Metaklasse innerhalb des abstrakten Syntaxbaums des UML-Metamodells traversiert, so können durch die API der Name, der Typ und alle seine Metaassoziationen und -attribute bestimmt werden, die als Instanzen Predicate, Type, Rule und allen anderen MIOElementen das MIOModell bilden. Damit ist durch den ersten Funktionsbereich mit dem MIOGenerator das MIOModell generiert worden, und es kann in einem nächsten Funktionsbereich aus diesem Zwischenmodell nun ziellogiksprachenspezifischer Code erzeugt werden, welcher in einer Ausgabedatei ausgegeben wird. Wird dem TargetLanguageGenerator das zielsprachenspezifische Backend bekannt gemacht, so muss auf dem MIOModell die accept-methode aufgerufen werden, die den Visitor das gesamte Zwischenmodell besuchen lässt. Wenn ein Element einen Visitor akzeptiert, so ruft es auf diesem seine zugehörige visit-methode auf, die spezifischen Code für dieses Element erzeugen lässt. Wird beispielsweise ein Predicate besucht, so muss in TyRuBa-Syntax nun eine neue Pädikatdefinition mit Namen, Parametertypen und der Angabe der Modi in die Ausgabedatei geschrieben werden. Für die Erzeugung von Prädikatdefinitionen ist die Angabe der Inferenzmodi unabdingbar. Metaklassen, -attribute und -assoziationen besitzen eine im UML-Metamodell spezifizierte Multiplizität, die auf Codeebene widergespiegelt werden muss. Die Tabelle 5.1 zeigt die Abbildung von Multiplizitäten auf ihren entsprechenden Inferenzmodus. MultiplicityInformation entsprechender Inferenzmodus 1 DET 0..* SEMIDET 1..* MULTI *..* NONDET Tabelle 5.1: Abbildung der Multiplizitäten auf Inferenzmodi 70

79 5.3 Teilsystem Model to Logic Transformation 5.3 Teilsystem Model to Logic Transformation Model to Logic Transformation (Mlt) ist ein weiteres Teilsystem, das für die Abbildung des Modells in Fakten einer Wissensbasis nötig ist. Es leistet die konkrete Codeerzeugung der Fakten, die sich aus dem Modell nach einer Transformation ergeben. Es arbeitet dabei gleichzeitig sowohl auf dem UML-Modell als auch auf dem MIOModell. Das UML-Modell dient dem Auslesen der Inhalte von Modellelementen und das MIOModell der Auswahl der korrekten Prädikate, die die Modellinformationen und -inhalte als Fakten darstellen. Abbildung 5.8: Verfeinerung der Aktion MLT ausführen aus Abbildung 5.2 Das Aktivitätsdiagramm in Abbildung 5.8 zeigt vorerst den Transformationsablauf, bevor das Design und die Implementierungsdetails des Teilsystems erläutert werden. Das Diagramm zeigt ähnlich wie MELT zwei Funktionsbereiche, die an der Transformation maßgeblich beteiligt sind. Der erste Bereich ist die Generierung des Abbildungsverzeichnisses, das, wie im Kapitel Generierung der Fakten auf Seite 45 beschrieben, die Transformation beschleunigt. Der zweite Funktionsbereich nutzt dieses Abbildungsverzeichnis, um das Modell letztlich in Fakten zu überführen Design Das Design dieses Teilsystems ist dem Aufbau von MELT ähnlich. Die Abbildung 5.9 zeigt eine Unterteilung des Teilsystems in die Pakete commandline und generator, welches das Unterpaket backend besitzt. 71

80 5 Design und Implementierung Abbildung 5.9: Designmodell von Mlt Paket commandline Das commandline-paket stellt ähnlich wie das gleichnamige Paket in MELT die Hauptklasse bereit, die der Benutzer anstoßen kann, um ein eingehendes UML- Modell zusammen mit dem MIOModell seines Metamodells in Fakten einer Ziellogiksprache zu transformieren und diese Fakten als Code der Logiksprache in einer Datei zu speichern. Paket backend Dieses Paket hält wiederum ein Backend-Interface, welches der Entwickler implementieren muss, um die Codegenerierung auf die Ziellogiksprache anzupassen. Auch hier erlaubt das Factory-Pattern die Integration verschiedener Backends, die auf unterschiedliche Logiksprachen zugeschnitten sein können. Die Integration eines Visitor-Patterns ist für diese Transformation nicht möglich, weil sich UML- Modellelemente in der EMF-API nicht mit den entsprechenden visit- und accept- Methoden erweitern lassen. 72

81 5.3 Teilsystem Model to Logic Transformation Paket generator Das generator-paket enthält die Klassen, die die Generierung der MetaMap und die Faktengenerierung vornehmen und deckt dadurch die zwei oben erwähnten Funktionsbereiche ab. Die Klasse MetaMap erzeugt als erster Funktionsbereich ein einmaliges Abbildungsverzeichnis, in dem für jede Metaklasse eines Modellelements nachgesehen werden kann, welche Modellinformation mit welchem Prädikat ein Fakt bildet. Abbildung 5.10: Beispielabbildung einer UML-Klasse mit einem Attribut und einer Operation, deren Inhalte auf bestimmte Prädikate abgebildet werden, damit sie einen Fakt erzeugen. Die Abbildung 5.10 zeigt die Klasse Kunde mit einem Attribut, einer Operation, die alle einen eindeutigen Index besitzen, des Weiteren eine Spalte mit einer Auswahl an Prädikatdefinitionen des MIOModells und eine Spalte mit einer Menge von Fakten, die es zu generieren gilt, indem Inhalte der ersten Spalte mit Definitionen der zweiten Spalte geeignet zusammengeführt werden. Damit aus diesen Elementen Fakten erzeugt werden können, die sie repräsentieren, müssen zu den einzelnen Modellelementen Abbildungen zu den Prädikaten gefunden werden, die die Inhalte korrekt ausdrücken. Beispielsweise gibt das Prädikat namedelement_name/2 den 73

82 5 Design und Implementierung Namen der Klasse als Fakt korrekt wieder, indem es hier dem Element mit dem Index 1 den Namen Kunde zuweist. Wie das Abbildungsverzeichnis entsteht, wird näher im Implementierungsabschnitt erörtert. Das Abbildungsverzeichnis muss nur ein einziges Mal erstellt werden und kann daraufhin für jedes Modellelement verwendet werden. Damit auf den Modellelementen geeignet gearbeitet werden kann, um sie in Fakten zu transformieren, müssen sie als Objekte in einer bestimmten Struktur, wie beispielsweise einer einfachen Liste, abgelegt werden. Diese Struktur wird in der Klasse ModelData gehalten und von der Klasse OutputModelGenerator erzeugt. Sie erlaubt es, jedes Modellelement einmal zu traversieren und für dieses Fakten zu generieren. Außerdem gestattet die Liste eine eindeutige Indizierung der Modellelemente, mit der sie später referenziert werden können. Auf der Klasse ModelData arbeitet die Klasse TargetProgramLangGenerator, die den zweiten Funktionsbereich, die Faktengenerierung, erfüllt, indem alle Modellelemente des UML-Modells mit entsprechenden Prädikaten des MIOModells verknüpft werden, um einen Fakt zu bilden Implementierung Vor dem letzten Transformationsprozess, der letztlich die Fakten zu einem Modell generiert, muss die MetaMap erzeugt werden, da sie die Transformation wesentlich beschleunigt und vor allem für weitere Transformationen nicht neu erstellt werden muss. Die Erstellung der MetaMap birgt die Problematik, dass eine Abbildung zwischen Elementen der UML aus der EMF-API mit den korrekten Prädikaten ermittelt werden muss. Die in dieser Arbeit umgesetzte Idee für die Generierung der Abbildung ist die folgende: Innerhalb des Ecoremodells (Abb. 5.7) des UML-Metamodells werden die Metaklassen durch eine EClass und ihre besitzenden Metaassoziationen und -attribute durch EReference beziehungsweise EAttribute, welche eine Spezialisierung von EStructuralFeature sind, ausgedrückt. Für jedes EStructuralFeature existiert zum einen genau ein Prädikat im MIOModell, welches es als Fakt darstellen kann und zum anderen genau eine Methode, die seinen Inhalt bestimmen kann. Prädikat und Methode bilden nun fortan ein wichtiges Paar innerhalb der Abbildung, da das Prädikat das Aussehen des Fakts angibt und die Methode den Inhalt bestimmt, mit dem die Parameter des Prädikats zu belegen sind. Wird nun zu jedem EStructuralFeature einer EClass ein Prädikat-Methoden-Paar gebildet, 74

83 5.3 Teilsystem Model to Logic Transformation so kann für eine Metaklasse bereits eine Abbildung angegeben werden, wie welcher Inhalt mit welchen Prädikat einen Fakt erzeugt. Eine Anwendung auf alle Metaklassen des UML-Metamodells führt zu dem vollständigen Abbildungsverzeichnis, das einer Metaklasse mehrere Prädikat-Methoden-Paare zuordnet. Es bleiben die Fragen offen, wie zum einen die Methode ermittelt werden kann, die den Inhalt eines EStructuralFeatures ausliest, und zum anderen das Prädikat zu demselben EStructuralFeature gefunden werden kann. Diese Fragestellungen werden in den Folgeabschnitten behandelt. Der erste Teil wird so realisiert, dass zu einer Metaklasse über Java Reflections die Methode ermittelt wird, die einen ähnlichen Namen wie das EStructuralFeature besitzt, dessen Inhalt bestimmt werden soll. Dadurch, dass UML-Modelle sowohl auf Implementationsebene als auch im Editor zur Modellierung in der EMF-API von dem Ecoremodell abhängen, besitzen die Metaklassen EStructuralFeatures, die prinzipiell denselben Namen tragen, wie die Methoden, die den Wert des Features auslesen. Die Einschränkungen, die es hier gibt, sind die, dass Methoden, die einen Wert zurückgeben meist den Präfix get tragen. Zum Beispiel wird das Metaattribut name einer Klasse mit der Methode getname() ausgelesen. Weitere Beschränkungen sind, dass manche Eigenschaften über eine gleichnamige Methode angesprochen werden, die neben ihrem Präfix zusätzlich die Mehrzahl der Eigenschaft ausdrücken. Zum Beispiel besitzt eine Class das Metaattribut ownedattribute, das in der API durch die Methode getownedattributes() angesprochen wird. Dabei sind die Sonderfälle in der englischen Pluralbildung auch zu beachten: y ies x ices Allerdings gibt es neben der Pluralbildung noch einen wichtigen Sonderfall. Die Metaassoziation class der Metaklasse Property kann nicht über die Methode get- Class() angesprochen werden, da diese bereits durch die abstrakte Klasse java.lang.object definiert ist. Die richtige Methode lautet für diesen Fall getclass_(). Unter Beachtung der Sonderfälle für Methodennamen kann somit zu einem EStructuralFeature die korrekte Methode ermittelt werden. Der zweite Teil ist etwas einfacher. Es gilt das Prädikat zu einem EStructuralFeature zu finden. Im Design-Abschnitt von MELT auf Seite 66ff ist erwähnt worden, 75

84 5 Design und Implementierung dass sich der Prädikatname aus dem Namen eines EStructuralFeature und dem Namen seiner definierenden Metaklasse zusammensetzt. Die Klasse MIOModel bietet Methoden an, Prädikate nach bestimmten Kriterien, wie ihr Name oder ihre Stelligkeit, zu suchen und diese zurückzugeben. Damit kann zu einem EStructuralFeature auch das entsprechende Prädikat gefunden werden. Für die Faktengenerierung muss nun über jedes Modellelement, das sich in Model- Data befindet, traversiert werden und im Abbildungsverzeichnis für die Metaklasse des Modellelements alle Prädikat-Methoden-Paare geholt werden, mit denen Fakten in eine Ausgabedatei geschrieben werden können. Hier gibt es noch einen Punkt zu beachten, der beim Auslesen des Modellelements durch die Methoden auftritt. Eine Methode kann als Rückgabewert den Wert null haben. Das bedeutet, dass das Modellelement keinen Inhalt oder keine Referenz zu einem anderen Element besitzt. Daher muss hierfür auch kein Fakt erzeugt werden. Die Erstellung der MetaMap ist durch die Restriktionen durch die UML-API bezüglich der Methodennamen und dem Ansprechen der Modellobjekte an ein Metamodell gebunden. Jedoch bleibt das Metamodell mit einer leichten Anpassung austauschbar und der Großteil der Implementierung von diesen Änderungen unbetroffen. 5.4 Teilsystem Benutzerschnittstelle Dieser Abschnitt behandelt die Realisierung einer Benutzerschnittstelle, mit der ein Benutzer Modelle in Fakten transformieren und eine Anfrageausführung beginnen kann. Die Benutzerschnittstelle ist durch einen Dialog zur Anfrageausführung, einen View, der Anfrageergebnisse anzeigt, und die Transformationen durch Aktionen in dem Kontextmenü des Dateibrowsers realisiert worden. Dafür ist es notwendig, Eclipse um diese Benutzerschnittstelle zu erweitern. Der folgende Unterabschnitt erläutert grundlegend, wie Aktionen in Kontextmenüs hinzugefügt, ein View zur Visualisierung genutzt werden kann, indem bestimmte Schnittstellen von Eclipse erweitert werden. Der zweite Unterabschnitt zeigt das Design dieses Teilsystems und erklärt die Aufgaben der Pakete und Klassen. 76

85 5.4 Teilsystem Benutzerschnittstelle Grundlagen eines Eclipse Plugins Dieser Unterabschnitt behandelt die Grundlagen, wie neue Funktionen zu Eclipse durch die Realisierung eines Plugins hinzugefügt werden können. Um dem Eclipse-Framework neue Funktionen hinzuzufügen, können neue Views, Menüaktionen oder Wizards implementiert werden, auf eine Extension zugreifen. Jene werden durch bereits existierende Plugins angeboten und bieten die Möglichkeit ihre Funktionalität zu erweitern [ClRu09] (S.81ff). Um eine definierte Extension zu nutzen, beispielsweise, um eine Menüaktion hinzuzufügen, muss dem Plugin, welches sie benutzt, diese Extension bekannt gemacht und eine Java-Klasse angegeben werden, die die neuen Funktionen implementiert. Jenachdem, welche Extension erweitert wird, muss die Klasse entsprechende Interfaces implementieren oder von einer Klasse erben. Das entwickelte Plugin nutzt Action- und View-Extensions, um die Benutzerschnittstelle zu realisieren, welche in den folgenden zwei Unterabschnitten erläutert werden. Actions Actions sind Funktionalitäten, die durch Mausklicks auf Menüeinträge und Buttons ausgeführt werden. Das Plugin org.eclipse.ui.popupmenus stellt die Extension zur Verfügung, einen neuen Menüeintrag in das Kontextmenü des Dateibrowsers einzufügen. Dieser Eintrag seinerseits kann entweder die Action sein, die bestimmte Funktionen ausführt, oder ein Untermenü für weitere Einträge sein. Jede Klasse, die diese Extension erweitert, implementiert das Interface IObjectActionDelegate, mit dem die Funktionen einer Aktion programmiert werden. Für das entwickelte Plugin ist ein Menüeintrag Modelquery in das Kontextmenü des Dateibrowsers aufgenommen worden, das vier Aktionen beinhaltet, welche später mit dem Design der Benutzerschnittstelle näher erläutert werden. Views Das Plugin org.eclipse.ui.view bietet eine Extension zur Erweiterung der Entwicklungsumgebung durch einen neuen View. Ein View bietet die Möglichkeit, Texte, Bilder oder Objekte tabellarisch oder hierarchisch anzuzeigen. Die Klasse, die den 77

86 5 Design und Implementierung neuen View implementiert, muss von ViewPart erben und die Interfaces IStructuredContentProvider und ITreeContentProvider, damit der Inhalt des View korrekt repräsentiert und visualisiert werden kann. Das entwickelte Plugin benutzt einen View, der die Ergebnisse einer Modellanfrage hierarchisch in einer Baumstruktur mit drei Ebenen anzeigt. Auf der ersten Ebene identifiziert es jeweils die Anfrage des Benutzers. Die zweite Ebene zeigt alle Ergebnisse einer Anfrage. Auf der dritten Ebene hingegen wird zu jedem Ergebnis eine Variablenbelegung mit den aus der Inferenz ermittelten Werten angegeben. Pluginklasse Jedes Eclipse-Plugin hat eine Pluginklasse, welches das Plugin von einem programmiertechnischen Standpunkt aus repräsentiert [ClRu09]. In diesem Plugin lautet die Pluginklasse Activator, die an dieser Stelle vorgestellt werden soll, da sie wichtige Funktionen erfüllt, die von den verschiedenen Teilsystemen genutzt werden. Die Klasse Activator ist die wichtigste Klasse des Plugins. Sie erbt von Abstract- UIPlugin und ist ein Singleton [GHJV95], da sie zur Laufzeit der Entwicklungsumgebung Eclipse nur einmal existieren darf. Das Plugin wird geladen sowie die Funktionen einer Klasse des Plugins benutzt werden. Bei Initialisierung wird in der Activator-Klasse die start()-methode aufgerufen, die zusätzliche Initialisierungen starten kann. In diesem Fall ist es das Anlegen der erwähnten MetaMap, da sie nur ein einziges Mal generiert werden muss, damit sie für jedes UML-Modell wiederverwendet werden kann, das MLT mit dieser MetaMap transformieren kann. Für die Erzeugung der MetaMap ist auch eine einmalige Erzeugung des MIOModells nötig, welches nach der Erstellung der Map wieder verworfen werden kann. Die Pluginklasse besitzt unter anderem Funktionen, mit denen sich Pfade zu einer im Dateibrowser ausgewählten Datei, zum Eclipse-Workspace und zu Plugineigenen Pfaden ermitteln lassen. Weiterhin speichert sie zu jedem Modell, auf dem bereits eine Anfrage getätigt worden ist, die Wissensbasis mit den Fakten des Modells und eigenen definierten Fakten, Regeln oder Typen in einem FrontEnd- Objekt, das eine Schnittstelle zur Wissensbasis von TyRuBa ist. Das FrontEnd kann über get- und set-methoden gesetzt oder zurückgegeben werden und durch eine create-methode neu erzeugt werden. Die Wissensbasis eines neuen FrontEnd s wird automatisch mit den Typen und Regeln geladen, die das UML-Metamodell abbilden. 78

87 5.4 Teilsystem Benutzerschnittstelle Die Speicherung der Wissensbasis beschleunigt die Anfrage auf einem Modell dadurch, dass für eine Anfrage auf dem Modell kein FrontEnd mehr erzeugt werden muss, das mit neu generierten Fakten des Modells, so wie den Prädikaten, die das UML-Metamodell abbilden, geladen werden muss. Der Nachteil ist hier, dass Modelländerungen zwischen einer vergangenen Anfrage und einer neuen unentdeckt bleiben. Daher können die Fakten aus der Wissensbasis wieder entladen werden, indem ein neues FrontEnd erzeugt wird. Hierfür ist die Aktion UnloadAction zuständig, die später erläutert wird. Die stop()-methode wird bei Beendigung des Plugins, also bei einem Schließen der Eclipse Entwicklungsumgebung ausgeführt. Sie dient hier der Speicherbereinigung. Das heißt, dass alle laufenden Threads, die das Plugin verursacht hat, beendet werden und jedes FrontEnd geschlossen wird, bevor Eclipse beendet wird Design Das Design des Teilsystems der Benutzerschnittstelle wird in Abbildung 5.11 gezeigt. Es sind die Pakete popup und view dargestellt, die zum einen die Aktionen der Kontextmenüeinträge und zum anderen die Visualisierung der Anfrageergebnisse als View implementieren. Abbildung 5.11: Design des Teilsystems Benutzerschnittstelle 79

88 5 Design und Implementierung Paket views: Aufgaben, Design und Implementierung Die Hauptklasse dieses Pakets ist die QueryView-Klasse, da sie diejenige ist, die in Eclipse den neuen View anzeigt. Der View ist ein Teilbereich der Benutzerschnittstelle, weil er dem Benutzer die Ergebnisse einer Modellanfrage durch eine Baumstruktur mit drei Ebenen anzeiget. Die erste Ebene identifiziert dabei eine Anfrage, die zweite jeweils ein Ergebnis einer Anfrage und die dritte Ebene für jedes Ergebnis eine Variablenbelegung mit einer gefundenen Lösung. Diese Baumstruktur wird durch die Klassen TreeParent und TreeObject wiedergegeben, die eine hierarchische Objektstruktur aufbauen. Die Klassen ViewContentProvider und ViewLabelProvider haben die Aufgabe, den Inhalt des Views, sprich die Baumstruktur, korrekt darzustellen. Das Updatable-Interface ist für die Aktualisierung des Views vorgesehen, falls sich an der Baumstruktur Änderungen, wie beispielsweise das Hinzufügen eines neuen Knotens ergeben. Für die Implementierung des Views spielen die Klassen ViewContentProvider und ViewLabelProvider eine wichtige Rolle, da sie die Interfaces IStructuredContent- Provider und ITreeContentProvider implementieren, die eine korrekte Darstellung der TreeObject-Objekte als Baum ermöglichen. Paket popup: Aufgaben, Design und Implementierung Das popup-paket enthält unter anderem die Klassen, die die Aktionen des eigenen Menüs ausführen und bilden somit den anderen Teilbereich der Benutzerschnittstelle. Die Aktionen sind in der Abbildung 5.11 dargestellt und befinden sich in dem Paket actions. Die vier Aktionen haben die folgenden Aufgaben: UnloadAction: Wie im Unterabschnitt Pluginklasse auf Seite 78 erwähnt, speichert das Plugin zu jedem Modell seine eigene Wissensbasis, die das Modell als Fakten hält und weitere Fakten, Regeln, Typdefinitionen besitzt, die der Benutzer zusätzlich eingegeben hat. Wenn das Modell geändert wird, so müssen die Fakten neu generiert werden und in die Wissensbasis geladen werden. Um die veralteten Fakten zu entladen, wird die UnloadAction benutzt. Das Plugin sucht dann für das durch den Klick selektierte Modell das entsprechende FrontEnd und schließt es. Model2LogicTransformer: Diese Aktion wandelt das im Dateibrowser selektierte Modell in Fakten um und speichert diese in einer TyRuBa-Sourcedatei. 80

89 5.4 Teilsystem Benutzerschnittstelle TyrubaCaller: Dieses ist eine Aktion, die nicht auf einem Modell, sondern auf bereits generierten Fakten eine Anfrage startet. Ähnlich zu einer Modell- Datei ist es hilfreich, diese Fakten in einem der Datei zugehörigen FrontEnd zu speichern, um weitere Anfragen auf diesen Fakten zu beschleunigen. Model2Query: Diese Aktion fasst die beiden Aktionen Model2LogicTransformer und TyrubaCaller zusammen und hält die Generation der Sourcedatei mit den Fakten verborgen. Die Aktion kann nur auf einem Modell aufgerufen werden. Das Plugin transformiert im Hintergrund das Modell in Fakten, die es in ein neues FrontEnd, falls nicht bereits vorhanden, lädt. Daraufhin wird der QueryDialog geöffnet, um mit TyRuBa zu interagieren. Auf Implementierungsebene implementiert jede Action-darstellende Klasse das Interface IObjectActionDelegate. Es stellt unter anderem die Methoden void run( IAction arg0) und void selectionchanged(iaction arg0, ISelection selection) bereit. Die run-methode implementiert dabei den Code, den die Aktion ausführen soll. In diesem Fall beispielsweise die Transformation eines Modells in Fakten mit einer Anfrageausführung. Durch die selectionchanged-methode kann über das ISelection-Objekt stets auf das im Dateibrowser selektierte Element, also ein UML-Modell, zugegriffen werden, um auf diesem die Aktion durchführen zu können. Klasse QueryDialog: Aufgaben und Implementierung Diese Klasse ist ein weiterer Teilbereich der Benutzerschnittstelle. Sie implementiert ein Dialogfenster, das geöffnet wird, wenn der Benutzer eine Aktion auf einem Modell gewählt hat, die eine Anfrage auf diesem Modell durchführt. Der Dialog ermöglicht dem Benutzer verschiedene Eingaben, die in die Wissensbasis aufgenommen werden können, womit der Benutzer indirekt mit dem Logikprogramm interagiert. Er kann beispielsweise einer Wissensbasis weitere Fakten übergeben oder auch neue Typen und Regeln definieren oder auf der Wissensbasis eine Anfrage ausführen. Die Abbildung 5.12 zeigt das QueryDialog-Dialogfenster. Es ist aus einer Combobox, in der sich Bezeichnungen für Regeln, Typdefinitionen oder Anfragen befinden und diese kurz beschreiben, aufgebaut. Eine Auswahl eines Elements verursacht eine Änderung des Textes im darunterliegenden Textfeld. Dieses Feld dient dazu, neue Regeln, Typen oder Anfragen syntaxkonform zu formulieren. Regeln und 81

90 5 Design und Implementierung Abbildung 5.12: Der QueryDialog, der die Interaktion mit TyRuBa ermöglicht Typdefinitionen können über den Button Save Type/Fact für spätere Anfragen gemerkt und aus der Combobox ausgewählt werden. Über den Button Add Type/Fact to factbase lassen sich formulierte Regeln, Fakten und Typdefinitionen der Wissensbasis hinzufügen. Der Button Load rub file fügt sogar eine komplette Sourcedatei in die Wissensbasis ein. Beim Laden einer externen Sourcedatei können automatisch neue Beschreibungen mit ihren zugehörigen Definitionen in die Combobox und in das Textfeld integriert werden. Hierfür kann im Vorfeld eine bestimmte Annotation im Sourcecode der TyRuBa-Datei benutzt werden, die bestimmte Stellen im Code markiert, die in das Dialogfenster als Auswahlmöglichkeit aufgenommen werden. Das Listing 5.1 zeigt eine solche Definition einer Annotation in einer Sourcedatei. 1 //@ 2 // All classes with their names 3 // begin_rft 4 :- Class (?x), 5 namedelement_name (?x,? name ). 6 // end_rft Listing 5.1: Annotation in einer TyRuBa Sourcedatei Eine Annotation wird durch //@ eingeleitet. Darauf folgt als Kommentar die Beschreibung des Codes, der annotiert wird. Die Beschreibung wird in der Combobox 82

91 5.5 Teilsystem Anfrageausführung erscheinen. Der Code, der in das Textfeld im Dialogfenster passend zu der Beschreibung angegeben werden soll, befindet sich zwischen den Kommentaren //begin_rft und //end_rft, die den Beginn und das Ende des Codes markieren. rft steht für rule,fact und type. Der annotierte Code ist hier eine Anfrage nach allen Klassen eines Modells, die einen Namen haben. Die Dialogklasse arbeitet eng mit der Klasse ExamQueries zusammen, die zur Laufzeit alle Beschreibungen und Texte, die das Dialogfenster anzeigt, hält und sich mit weiteren Regeln, Typdefinitionen und Fakten erweitern lässt. Die Klasse ist ein Singleton, damit bei allen Anfragen auf verschiedenen Modellen auf bereits definierte Anfragen, Regel und Typdefinitionen zugegriffen werden kann und sie nicht neu formuliert werden müssen. Das Dialogfenster ist außerdem mit ein paar einfachen Anfragetexten vorbelegt, die der Softwareentwickler benutzen kann. Über den OK -Button lässt sich schließlich eine Anfrage starten. Fehler bei der Eingabe des Quellcodes werden dem Benutzer durch Nachrichtendialoge angezeigt und können berichtigt werden. Dadurch, dass der Dialog modal ist, birgt er ein Hindernis bezüglich des Zugriffs auf die Wissensbasis eines ausgewählten Modells. Die Wissensbasis wird als FrontEnd im Moment der Ausführung einer Aktion von der Aktion selber gehalten und nicht an das Dialogfenster weitergereicht. Damit neue Sourcedateien, Regeln, Fakten und Typdefinitionen dem FrontEnd hinzugefügt werden können, wird die Aktion über die Nutzung des Observer-Patterns (siehe [FBus96], Seite 339) benachrichtigt, neues Wissen in das FrontEnd der selektierten Datei aufzunehmen. 5.5 Teilsystem Anfrageausführung Dieser Abschnitt beschäftigt sich mit dem Teilsystem der Anfrageausführung. Das Plugin arbeitet hier eng mit dem Logikprogramm TyRuBa zusammen, um mit dessen Schnittstelle eine Anfrage auf Modellfakten auszuführen und Benutzereingaben über die Definition weitere Regeln, Typen und Fakten an das Logikprogramm weiterzureichen. 83

92 5 Design und Implementierung Design Die Abbildung 5.13 zeigt das Design des Teilsystems mit dem Paket threads, das die Klassen enthält, die die Funktion des Teilsystems implementieren und dem Paket TyRuBa mit der bereits erwähnten FrontEnd-Klasse. Abbildung 5.13: Design des Teilsystems der Anfrageausführung Paket threads: Aufgaben, Design und Implementierung Das Paket threads realisiert das Teilsystem der Anfrageausführung. Anfragen auf die Wissensbasis werden als ein nebenläufiger Prozess ausgeführt, da eine Inferenz je nach Anfrage und Größe der Wissensbasis einige Zeit in Anspruch nehmen kann. Das bringt den Vorteil mit sich, dass Eclipse weiterhin benutzbar bleibt und nicht durch die Inferenz blockiert wird. Somit lassen sich auch mehrere Anfragen gleichzeitig starten. Das Paket enthält die zwei Klassen ThreadControl und QueryThread. Beide erben von Java-Threads und erfüllen unterschiedliche Aufgaben: Die ThreadControl ist ein Singleton. Sie wird zusammen mit dem Pluginstart instanziert und existiert nur einmal zur Laufzeit. Die Aufgabe ist es, alle Query- Thread s zu überwachen und ihren Status oder ihr Ergebnis im QueryView anzuzeigen. Wenn ein QueryThread beendet ist, so wird aus dem View die entsprechende Information über den Status einer Anfrage gelöscht und statt dessen das Ergebnis der Anfrage, die der QueryThread bearbeitet hat, angezeigt. Jeder QueryThread wird in der ThreadControl erzeugt und gestartet. Dies bietet die Möglichkeit, die Zeit der Inferenz zu messen. Der QueryThread ist die Klasse, die eine Anfrage auf einer Wissensbasis mit dem Logikprogramm TyRuBa durchführt. Über die QueryIf -Schnittstelle kann dieser 84

93 5.6 Exemplarischer Ablauf Thread auf das entsprechende FrontEnd zugreifen, das die Modellfakten des durch die Aktion ausgewählten UML-Modells aus dem Dateibrowser besitzt. Das Listing 5.2 zeigt einen Auszug aus QueryThread, der eine Inferenz startet. 1 // set up a tyruba query 2 Connection conn = new Connection ( frontend ); 3 Query stat = conn. createquery (); 4 ResultSet results ; 5 try { 6 results = stat. executequery ( rule ) ; 7 } catch ( final TyrubaException e) {} Listing 5.2: Auszug aus QueryThread, wie eine Anfrage ausgeführt wird Zuerst wird eine Connection angelegt, die eine Verbindung zu TyRuBa aufbaut, und ihr das FrontEnd übergeben. Nun lässt sich durch diese Connection ein Query- Objekt initialisieren, das durch den Aufruf von executequery(rule) die Inferenz beginnt. Der Parameter rule ist ein String, in dem die Anfrageformulierung in TyRuBa-Syntax steht, z.b.: :-Class(?index)., welche alle Klassen eines Modells ermittelt. Nach der Inferenz liefert die Methode ein ResultSet-Objekt zurück. Dieses Objekt ist eine Liste, über die mit einem Iterator iteriert werden muss, um alle Ergebnisse der Inferenz, sprich eventuelle Variablenbelegungen, auszulesen. Auf dem ResultSet kann mit der Methode getstring(string varname) der zu einem Variablennamen korrespondierende Wert als String ermittelt werden. 5.6 Exemplarischer Ablauf Das Sequenzdiagramm in Abbildung 5.14 zeigt einen Beispielablauf des Plugins, wenn der Softwareentwickler auf einem UML-Modell die Aktion Model2Query ausführt. Im Vorfeld ist von der Activator-Klasse die MetaMap erzeugt worden. Die Aktion Model2Query holt sich ein neues Mlt-Objekt von der Plugin-Klasse, mit dem sich die Transformation in TyRuBa-Fakten durchführen lässt. Als nächstes holt sich die 85

94 5 Design und Implementierung Action-Klasse den absoluten Pfad zur Modelldatei und überprüft, ob es für eine Transformation gültig ist. Dies ist der Fall, wenn es sich um ein Modell der UML handelt, wovon in diesem Beispiel ausgegangen wird. In Schritt sechs holt sich die Klasse das FrontEnd zum selektierten Modell. Die Alternative im Sequenzdiagramm zeigt den Fall auf, dass für ein selektiertes Modell noch keine Wissensbasis existiert. Für diesen Fall wird die Plugin-Klasse angewiesen, ein neues FrontEnd zu instanzieren und es mit den Prädikaten und Regeln, die die UML abbilden, zu füllen. Daraufhin wird die run-methode aus Mlt benutzt, um die modellrepräsentierenden Fakten zu generieren und diese in die Wissensbasis mit aufzunehmen. Das neu entstandene FrontEnd wird für spätere Anfragen im Activator für das selektierte Modell als Wissensbasis vorgemerkt. Als nächster Schritt wird ein QueryDialog instanziert, in dem sich die aktuelle Aktion als Observer registrieren kann, um das FrontEnd gegebenenfalls um Wissen zu erweitern. Daraufhin wird der Dialog geöffnet, in dem der Nutzer verschiedene Eingaben tätigen kann. Die folgende Alternative im Diagramm zeigt den weiteren Verlauf, wenn der Benutzer den Ok-Button geklickt hat. Im Falle des Abbrechen- Buttons wäre der Ablauf zu Ende. Wenn der Dialog geschlossen worden ist, werden die vom Benutzer eingegebene Beschreibung und Anfrage nacheinander ausgelesen und ein QueryThread-Objekt angelegt. Dieser Thread wird der ThreadControl- Instanz mit der Methode addthreadandstart(querythread qt) übergeben, die das Objekt zur Überwachung in eine Liste aufnimmt und den Thread als nebenläufigen Prozess abfährt. Dieser letzte Aufruf ist im Sequenzdiagramm als asynchron eingezeichnet, da die Aktion nicht auf die Rückkehr des QueryThread s wartet. Wenn eine Anfrage abgearbeitet worden ist, meldet der QueryThread seine Ergebnisse direkt an den QueryView. Zum Abschluss der Aktion Model2Query trägt sie sich als Observer wieder aus dem Dialog aus, damit sie nicht fälschlicherweise über unkorrekte Mitteilungen informiert wird. 5.7 Zusammenfassung Dieses Kapitel hat beschrieben, wie die Konzeptionen der Modell-zu-Fakten-Transformation des vorangegangenen Kapitels in Teilsysteme umgesetzt worden ist, und diese Teilsysteme zusammen mit einer Benutzerschnittstelle in einem Eclipse- Plugin für eine Anfrageausführung mit TyRuBa realisiert worden sind. Damit auf einem Modell eine Anfrage mit einem Logikprogramm möglich ist, ist als erster Schritt eine Transformation des Metamodells in Typ-, Prädikat- und 86

95 5.7 Zusammenfassung Regeldefinitionen der Zielsprache nötig gewesen. Diese Definitionen sind in einem zweiten Schritt wiederverwendet worden, um sie für die Transformation des Modells in Fakten zu nutzen. Als Ergebnis beider Transformationen haben sich zwei Sourcecode-Dateien für TyRuBa ergeben, eine mit den Definitionen von Typen, Prädikaten und Regeln, die andere mit den Modellfakten, die beide in die Wissensbasis des Logikprogramms geladen werden können. Die Funktionen des implementierten Plugins erlauben dem Benutzer eine Interaktion mit dem Programm und eine Formulierung einer Anfrage, die abgeleitet wird. Über einen View wird der Benutzer zu den Ergebnissen von Anfragen durch eine Baumansicht informiert. Das entwickelte Plugin kann nun für die Modellierung eingesetzt werden, indem es sie dahingehend unterstützt, ein Modell auf Eigenschaften oder bestimmte Strukturen zu überprüfen, was im nächsten Kapitel anhand des CoCoME-Modells erklärt wird. 87

96 5 Design und Implementierung 88 Abbildung 5.14: Sequentieller Ablauf der Aktion Model2Query

97 6 Anwendung Dieser Abschnitt befasst sich mit der Anwendung des entwickelten Programms auf das Beispielmodell CoCoME und zwei verschiedene Erweiterungen des Beispiels. Das UML-Modell von CoCoME ist aus dem Java-Sourcecode mit dem Modellierungstool Topcased [TopOrg] gewonnen worden, das den Code in ein UML-Modell im XMI-Format transformiert hat. Wie bereits angesprochen, enthält das Beispiel ein dreischichtiges Informationssystem, welches durch das Werkzeug auf seine Striktheit überprüft werden soll. Dieser Test wird im ersten Abschnitt behandelt. Als zweite Beispielanwendung, wird im Folgeabschnitt das Designmodell von Co- CoME um eine neue Funktion sinnvoll erweitert, jedoch bewusst ein typischer Fehler eingebaut, der dem Modellierer unterlaufen kann. Auch hier soll das Werkzeug entstandene Inkonsistenzen bei der Modellierung des Designmodells gegenüber den Anforderungen des Architekturmodells detektieren und dem Modellierer zur Korrektur anzeigen. Der dritte Abschnitt behandelt eine andere Art der Erweiterung des CoCoME-Modells, indem nicht eine neue Funktion auf Designebene eingeführt werden soll, sondern sich die Architektur des Systems durch Hinzunahme einer weiteren Schicht ändert. Diese Änderung schlägt sich auch auf der Designebene nieder, so dass einige Klassen für die Verwendung der Schnittstellen, die die zusätzliche Schicht bereitstellt, angepasst werden müssen. Das Werkzeug soll wieder einmal überprüfen, ob das Designmodell den Anforderungen der Architektur genügt. 6.1 Überprüfung von CoCoME Dieser Abschnitt beschreibt die Anwendung des entwickelten Werkzeugs auf das aus dem Sourcecode gewonnene CoCoME-Modell. Die Aufgabe besteht darin, dass im Modell enthaltene dreischichtige Informationssystem auf eine Striktheit zu überprüfen, die durch die Architektur definiert worden ist. Das Werkzeug kann benutzt werden, indem im Eclipse Navigator auf das CoCoME- Modell rechtsgeklickt wird und aus dem Kontextmenü der Eintrag Modelquery 89

98 6 Anwendung Make query ausgewählt wird. Das Werkzeug transformiert das angeklickte Modell in Fakten und schreibt diese in die Wissensbasis, in der sich bereits alle Typ-, Regel- und Prädikatdefinitionen zu UML-Metamodell befinden. Nach der Transformation in Fakten öffnet sich der QueryDialog, mit dem der Wissensbasis weitere Fakten hinzugefügt werden können oder eine Anfrage formuliert werden kann, die ausgeführt werden soll. An dieser Stelle müssen der Wissensbasis Fakten übermittelt werden, die anzeigen, welche Schichten das Modell besitzt, welche Pakete des Modells jeweils eine Schicht repräsentieren und wie die Schichten voneinander abhängen dürfen, damit die Striktheit zwischen den Schichten ausgedrückt werden kann. In das Textfeld müssen also die Fakten, wie sie bereits in den Listings 4.5 und 4.7 konzeptioniert worden sind, aufgeschrieben werden und der Wissensbasis hinzugefügt werden. Damit ist der Wissensbasis nun bekannt, dass es die drei Schichten gui, application und data gibt, welche Pakete des Modells einer Schicht zugeordnet sind, beispielsweise ist das Paket Cocome::org::cocome::tradingsystem::inventory ::gui der GUI-Schicht zugewiesen, und dass es eine Abhängigkeit der GUI-Schicht von der Applikationsschicht und eine Abhängigkeit der Applikationsschicht von der Datenhaltungsschicht gibt. Mit der Aufnahme der Fakten über die Schichtung der Pakete und ihrer Abhängigkeiten, kann nun angefragt werden, ob es Modellelemente gibt, die andere Elemente so referenzieren, dass die Abhängigkeit der Elemente voneinander der definierten Abhängigkeit der Schichtenpakete entgegen gerichtet ist. Diese Überprüfung findet mit der Anfrage auf die Regel getillegalreferences(?element,?fromlayer,? tolayer) statt. Die Anfrage auf dem CoCoME-Modell ergibt 28 Verletzungen von Elementen gegen die definierten Abhängigkeitsbeziehungen der Schichten. Alle Verstöße sind Abhängigkeitsbeziehungen der Datenhaltungsschicht von der Applikationsschicht. Bei den verletzenden Elementen handelt es sich jeweils um TypedElements, also konkret um Elemente der Metaklasse Property und Parameter, die innerhalb des data-pakets deklariert sind und einen Typen besitzen, der im application-paket definiert ist. Es handelt sich hierbei bei um den Datentypen Collection, welcher von allen verletzenden Elementen referenziert wird. Dies wirft nun die Frage auf, wie diese Verletzungen auftreten konnten. Die Antwort lässt sich bei der Transformation des Java-Sourcecodes in ein UML-Modell durch das Modellierungstool Topcased finden. Bei der Collection handelt es sich um den Datentypen, welcher sich im Java-Framework im Paket java.util befindet. Dieses Paket wird jedoch bei der Transformation nicht aufgelöst, weil es nicht 90

99 6.2 Erweiterung von CoCoME auf dem Designmodell vom Benutzer erstellt worden ist und wird daher auch nicht im Modell dargestellt. Bei der Transformation wird nun im Sourcecode der Datentyp Collection gelesen, für den fortan im Modell ein DataType-Element an der Stelle angelegt wird, an dem der Transformationsprozess steht, statt in einem entsprechen Paket java::util. Dadurch ist im Paket application dieser Datentyp angelegt worden und wird immer dann referenziert, wenn andere Modellelemente seinen Typen benutzen. Dieses Problem kann ganz einfach dadurch gelöst werden, dass der Collection- Datentyp aus dem Applikationsschichtpaket genommen und innerhalb eines anderen Pakets modelliert wird, welches sich außerhalb des Informationssystems befindet, da es viele Klassen gibt, die diesen Typen referenzieren. Eine Möglichkeit wäre es beispielsweise, außerhalb des Informationssystems ein Paket anzulegen, welches alle Datentypen des Modells besitzt. Nach der Auslagerung des Datentyps und einer weiteren Anfrage auf das Modell liegt nun eine korrekte strikte Schichtenarchitektur als Ergebnis vor. 6.2 Erweiterung von CoCoME auf dem Designmodell Dieser Abschnitt beschäftigt sich mit einer Erweiterung des CoCoME-Modells. Es wird hierbei angenommen, dass ein Softwareentwickler für das CoCoME-System eine neue Funktion implementieren soll. Es soll möglich sein, dass über einen Suchen- Knopf ein Suchen-Dialogfenster geöffnet werden soll, dass die Suche nach einem bestimmten Produkt gestattet und alle Informationen zu dem gefundenen Produkt ausgibt. Der Button und das Dialogfenster sollen als eigenständige Klassen implementiert werden. Die Klasse Store im Paket cocome::org:cocome::tradingsystem::inventory::gui::store implementiert eine Client-seitige Benutzerschnittstelle, an der der Filialenleiter den Warenbestand des Supermarktes einsehen, neue Waren bestellen oder der Lagermitarbeiter neue Produkte registrieren kann. Diese Nutzerschnittstelle besitzt bereits einen Refresh- und einen Order-Knopf, mit denen sich der Warenbestand aktualisieren lässt beziehungsweise neue Waren bestellen lassen. Innerhalb dieses Pakets modelliert der Softwareentwickler den neuen Button und den Dialog, der die Suchfunktion durchführen soll. Die Abbildung 6.1 zeigt einen Ausschnitt aus dem Gesamtmodell. Er fokussiert dabei auf die Main-Klasse Store, alle Buttons, die neu hinzugekommenen Klassen sowie auf alle Abhängigkeiten, die zwischen den Schichtpaketen bestehen. 91

100 6 Anwendung Abbildung 6.1: Auszug aus dem gesamten CoCoME-Modell mit der Erweiterung eines Suchen-Buttons Der Softwareentwickler hat nun in dem neuen Modell die neue Klasse SearchDialog so modelliert, dass die Operation searchfor den Rückgabewert Product besitzt, womit die Dialog-Klasse von der Produkt-Klasse abhängt. Der Grund für die Wahl dieser Abhängigkeit seitens des Entwicklers ist der, dass der Softwareentwickler sehr vertraut mit dem Umgang von Datenbanken ist und er sich so die Suche nach einem Produkt dadurch erleichtert, dass er direkt in der Datenhaltungsschicht dieses Produkt sucht. Damit ist der Modellierungsprozess abgeschlossen und das Modell kann wieder auf die Einhaltung einer strikten Schichtenarchitektur überprüft werden. Für die Überprüfung wird wie im vorangegangenen Abschnitt vorgegangen werden, indem alle Fakten über die definierten Schichten, ihren zugehörigen Paketen und erlaubten Abhängigkeiten in die Wissensbasis eingegeben werden und die Anfrage gestartet wird. Das Werkzeug meldet eine gefundene Lösung zurück und zeigt dem Benutzer ein Element an, welches eine Verletzung der Schichtenarchitektur erzeugt hat. Es handelt sich hierbei um die neu hinzugefügte Methode searchfor der SearchDialog-Klasse. Diese Operation verletzt die verbotene Abhängigkeitsbeziehung der GUI-Schicht von der Datenhaltungsschicht, da sie in der GUI-Schicht definiert ist und ihr Rückgabewert mit einem Modellelement aus der Datenhaltungsschicht 92

101 6.3 Erweiterung von CoCoME durch eine neue Architektur typisiert ist. Der Entwickler verletzt somit unbewusst zwei Anforderungen, die das CoCoME-Modell ursprünglich forderte. Zum einen entsteht durch die neue Abhängigkeitsbeziehung der SearchDialog-Klasse von der Product-Klasse eine neue Schichtenübergreifende Abhängigkeitsbeziehung zwischen den Schichten gui und data und zum anderen wird die Handhabung von Transferobjekten, die die GUI benutzt, verletzt, da der Zugriff auf die Datenschicht nicht service-orientiert ist, sondern direkt mit Objektreferenzen gearbeitet wird. Die zweite Tatsache ist zwar nicht Gegenstand der Überprüfung gewesen, jedoch ergibt sie sich direkt aus dieser Art der Schichtenverletzung. Somit konnte ein entstandener Fehler im Modell durch das Werkzeug detektiert werden. Er kann dadurch behoben werden, indem die Suchen-Methode nicht mehr direkt auf die Datenhaltungsschicht zugreift, sondern Methoden benutzt, die von der Applikationsschicht angeboten werden oder noch implementiert werden müssen. Diese Methoden wiederum dürfen auf die Datenebene zugreifen. Die Erweiterung dieses Beispiels zeigt einen typischen Fehler, der auftreten kann, wenn eine neue Funktion (nachträglich) in ein System eingefügt wird, weil sich beispielsweise die Systemanforderungen geändert haben. Dieser Fehler kann zum einen aus Flüchtigkeit entstehen, weil der Modellierer nicht genügend Kenntnisse über die Architektur und den Anforderungen des Systems besitzt oder zum anderen aus Gründen der Einfachheit. Es ist für den Programmierer in diesem Fall leichter gewesen, die Datenbank direkt anzufragen, als sich in das bestehende System einzuarbeiten und entsprechende Funktionen der Applikationsschicht für die neue Such-Funktion zu benutzen. 6.3 Erweiterung von CoCoME durch eine neue Architektur Als letzte Beispielanwendung des Werkzeugs wird diesmal eine Erweiterung des CoCoME-Modells betrachtet, bei der sich die Architektur des Informationssystems ändert. Es sei angenommen, dass sich die Systemanforderungen dahingehend ändern, dass das System nun personalisiert werden soll. Ein Filialenleiter oder ein Lagerarbeiter können sich an dem Server-Computer der Filiale nur mit ihren persönlichen Zugangsdaten über den Client-Rechner einloggen und erst dann Waren bestellen, eintragen oder Preise ändern. 93

102 6 Anwendung Die Architektur des Informationssystems wird um eine vierte Schicht, der Support- Schicht, erweitert. Abbildung 6.2 zeigt die nun nicht mehr strikte Schichtenarchitektur. Abbildung 6.2: Die neue 4-Schichtenarchitektur und ihre Abhängigkeitsbeziehungen Diese Schicht wird von jeder Schicht der vorangegangen dreischichtigen Architektur referenziert, da sie ihnen eine gemeinsame Funktionalität anbietet. Hierbei handelt es sich um einen Autorisierungsmechanismus, mit dem jede Schicht beispielsweise Benutzerrechte abfragen kann, um Benutzerfunktionen einzuschränken. Somit können auf der Präsentationschicht beispielsweise Benutzerfunktionen dahingehend eingeschränkt werden, dass Buttons abgeschaltet werden, damit der Benutzer sie nicht anklicken kann. Die Anwendungsschicht kann bestimmte Funktionalitäten, die sie erfüllt, einschränken und nicht für jeden Systemnutzer anbieten. Auf der Datenhaltungsschicht wiederum kann der Autorisierungsmechanismus dazu führen, dass der Zugriff und die Manipulation persistenter Daten für einen Benutzer eingeschränkt oder gar nicht möglich ist. Damit ist klar, dass die Funktionalität der Autorisierung in eine zusätzliche Schicht, also die Support-Schicht, gehört und von den anderen Schichten referenziert wird. Die Support-Schicht benötigt einen Zugriff auf eine Datenbank, in der die Daten von Benutzerkonten persistent gespeichert werden können. Es bietet sich an, hierfür die DataIf -Schnittstelle zu benutzen, die die Datenhaltungsschicht bereits anbietet. Die Abbildung 6.3 zeigt etwas detailierter das neue Design des Modells. Die drei Pakete gui,application und data besitzen jeweils eine Abhängigkeit von der AuthoriseIf -Schnittstelle, da einige Klassen der Pakete, welche in dem Design 94

103 6.3 Erweiterung von CoCoME durch eine neue Architektur Abbildung 6.3: Das Design der vier-schichtenarchitektur nicht weiter aufgezeigt werden, diese gemeinsame Schnittelle benutzen, um Berechtigungen für die Benutzung des Systems einzuholen. Des Weiteren greift sie auf die Datenbank des CoCoME-Systems zu, damit Benutzerkonten geladen und gespeichert werden können. Bevor dieses neue Modell nun darauf überprüft wird, ob alle geforderten Abhängigkeitsbeziehungen eingehalten werden, müssen im Gegensatz zu den anderen beiden Beispielanwendungen diesmal noch Fakten über die neue Schicht und ihre Abhängigkeiten der Wissensbasis hinzugefügt werden. Das Listing 6.1 zeigt, wie entsprechende Fakten im QueryDialog der Wissensbasis bekannt gemacht werden. Eine Anfrage auf die Regel getillegalreferences(?element,?fromlayer,?tolayer) ermittelt wiederum alle diejenigen Elemente, welche eine Abhängigkeitsbeziehung zwischen Schichten definieren, die nicht erlaubt ist. TyRuBa liefert für dieses Beispiel mit der neuen 4-Schichtenarchitektur ein Ergebnis zurück. Dieses zeigt eine unerlaubte Abhängigkeit der Klasse AuthoriseImpl innerhalb der Support-Schicht auf die DataIf -Schnittstelle der Datenhaltungsschicht, da diese Schnittstelle zum Speichern von Daten referenziert wird. Durch die Überprüfung mit Hilfe des Werkzeugs konnte die Inkonsistenz zwischen dem Architekturmodell und dem Designmodell zwar erkannt werden, dennoch ist die Lösung des Problems nicht ganz einfach und hält unterschiedliche Diskussi- 95