Softwaretechnik I, WS 2009/10 Modellbasierte Softwareentwicklung mit EMF Übungsblatt 5 13. November 2009 Organisatorisches Zur Bearbeitung der Übungsaufgabe stehen Ihnen die folgenden 3 Wochen (Kalenderwochen 47, 48 und 49) zur Verfügung. Während dieser Zeit finden die Übungen im Poolraum H-C 8327 statt. Die Lösungen für Übungsaufgabe 5 müssen nicht abgegeben werden, sondern werden im Rahmen eines kurzen Vortrags von ca. 10 Minuten Dauer präsentiert. Die Termine für die Kurzpräsentationen werden individuell im Rahmen der folgenden 3 Übungstermine vereinbart. Eine Einführung zur Arbeit mit EMF sowie weiterführende Literaturhinweise finden Sie unter der folgenden URL: http://pi.informatik.uni-siegen.de/mitarbeiter/kehrer/lehre/ws09/st1/ emf-intro/ Einführung Gegenstand dieser Übungsaufgabe ist die Übersetzung von Entity-Relationship (ER) Modellen in Schemadefinitionen eines relationalen Datenbankmanagementsystems (RDBMS). Eine solche Transformation ist eine der häufigsten Aktivitäten im Rahmen eines Software-Entwicklungsprozesses. Ist die Struktur der zu transformierenden ER-Modelle formal festgelegt, so lässt sich diese Transformation automatisieren. Im Rahmen dieser Übungsaufgabe werden wir einen solchen Transformator entwickeln. Grundlagen Auch Sicht des zu erstellenden Transformators (auch als Generator bezeichnet) stellen die zu verarbeitenden ER-Modelle Nutzdaten dar. Die Struktur dieser Daten kann durch ein Datenmodell definiert werden. Dieses bezeichnen wir im Folgenden als ER-Modell-Datenmodell. Da das ER-Modell-Datenmodell die abstrakte Syntax einer Modellierungssprache beschreibt, spricht man hier in der modellbasierten Softwareentwicklung (MBSE) auch von einem Metamodell. Die Ausgabe unserer Transformation sind Tabellendefinitionen. Zur Spezifikation der Tabellen verwenden wir die Structured Query Language (SQL). SQL ist eine Datenbanksprache zur Definition, Abfrage und Manipulation von Daten in relationalen Datenbanken. Im Rahmen dieser Übung ist lediglich der Sprachanteil zur Definition eines Datenbankschemas (Data Definition Langauge, kurz DDL) relevant, wobei wir auch hier nur eine Teilmenge aller existierenden DDL-Befehle benötigen werden. Abbildung 1 skizziert die an unserer Transformation beteiligten Komponenten und deren Beziehungen. 1
Abbildung 1. Beteiligte Komponenten und deren Beziehungen Vorgehen Das Vorgehen zur Bearbeitung der Übungsaufgabe lässt sich in folgende Schritte untergliedern, welche in mehreren Iterationen durchlaufen werden können: Schritt 1: Definition eines geeigneten ER-Modell-Datenmodells (ER-Metamodell) Schritt 2: Erstellung eines exemplarischen ER-Modells als Instanz dieses ER-Metamodells Schritt 3: Implementierung des Generators in Java Schritt 1: Definition eines Datenmodells für ER-Modelle In diesem Schritt soll ein geeignetes Metamodell für ER-Modelle definiert werden. Ein solches Metamodell können wir, wie bereits in der Einführung beschrieben, als Datenmodell auffassen, welches den strukturellen Aufbau von ER-Modellen beschreibt. Die zu modellierenden Nutzdaten stellen in diesem Fall also ER-Modelle dar. Die Modellierungssprache Ecore Mit Hilfe von EMF können beliebige Datenmodelle in der Modellierungssprache Ecore erstellt werden. Die Syntax des grafischen Diagramm-Editors ist dabei an die aus der UML bekannten Klassendiagramme angelehnt. Die wichtigsten Modellierungs-Konstrukte sind Klassen (EClass), Attribute (EAttribute) und Assoziationen/Kompositionen (EReference). Weiterhin spezifiziert Ecore eine Menge elementarer Datentypen. Im Rahmen dieser Übungsaufgabe werden die beiden Datentypen EString und EInt verwendet. Ein weiteres nützliches Element der Modellierungssprache Ecore ist die Enumeration (EEnum), für welche eine Menge an Enumerations-Literalen (EEnumLiteral) spezifiziert werden kann. Das ER-Modell-Datenmodell Das ER-Modell-Datenmodell legt den strukturellen Aufbau von ER-Modellen fest. Unsere vereinfachten ER-Modelle sollen dabei folgende Eigenschaften besitzen. Ein ER-Modell hat einen Namen und besteht aus Entitätstypen und Beziehungstypen. Entitätstypen haben einen Namen und besitzen Attribute. Wir vereinfachen unsere ER-Modelle dahingehend, dass genau ein Attribut den Primärschlüssel einer Entität darstellt. Attribute haben einen Namen und einen Datentyp, wobei wir uns auf die elementaren Datentypen String, Number und Date beschränken wollen. Ein Beziehungstyp, welcher ebenfalls einen Namen hat, setzt sich aus einer beliebigen Anzahl (mindestens jedoch 2) an Rollen zusammen. Über eine Rolle wird genau eine Entität referenziert. Darüber hinaus kann einer Rolle ein Name und eine Kardinalität zugeordnet werden. Als mögliche Kardinalitäten für Beziehungstypen beschränken wir uns auf die Werte 1 ( zu-1-beziehung ) und -1 ( zu-n-beziehung ).
Erstellen Sie das ER-Modell-Datenmodell mit Hilfe des durch EMF bereit gestellten Diagramm-Editors zur Spezifikation von Ecore-Modellen. Verwenden Sie für den Projektnamen wie auch für den Namen der Ecore-Datei den Bezeichner ERDataModel. Sie vermeiden dadurch Namenskonflikte mit dem für Schritt 3 bereit gestellten Eclipse Projekt-Gerüst. Schritt 2: Erstellung eines exemplarischen ER-Modells Konkrete Nutzdaten, in unserem Fall also ER-Modelle, können ebenfalls in einem von EMF bereit gestellten Editor spezifiziert werden. EMF stellt dabei sicher, dass nur korrekt aufgebaute ER-Modelle (korrekt im Sinne unseres bereits definierten ER-Modell-Datenmodells) erstellt werden können. Die zu modellierende fachliche Domäne wird ein Fußballspiel sein, weshalb wir das zu erstellende ER- Modell im Folgenden als Fussball-ER-Modell bezeichnen. Es soll folgenden Anforderungen genügen: Als durch einen Eintitätstyp zu modellierende Entitäten betrachten wir Spieler, Mannschaften und Spiele. Spieler und Mannschaften können anhand ihres Namens eindeutig identifiziert werden. Ein Spiel kann anhand einer Kennziffer eindeutig identifiziert werden und soll durch weitere Eigenschaften wie bspw. den Endstand näher beschrieben werden können. Darüber hinaus sollen folgende Beziehungen erfasst werden. Spieler können als Mitglieder einer Mannschaft zugeordnet werden, wobei jeder Spieler nur bei höchstens einer Mannschaft spielen darf. Einer Mannschaft gehört somit eine unbestimmte Anzahl an Spielern an. Eine 3-stellige Beziehung ordnet einem Spiel genau eine Mannschaft als Heim- und eine als Auswärts-Mannschaft zu. Weiterhin sollen alle durch eine Beziehung zwischen Spielern und Spielen alle Torschützen eines Spiels erfasst werden. Erstellen Sie ein Fussball-ER-Modell mit Hilfe des EMF-eigenen, generischen Modell-Editors zur Bearbeitung von Instanzen eines Ecore-Modells. Schritt 3: Implementierung des Generators In diesem Teil der Übung soll der eigentliche Transformator, welcher ein beliebiges ER-Modell in ein entsprechendes Schema eines RDBMS überführt, in Java implementiert werden. Für die Implementierung unseres Transformators ist ein eigenes Eclipse-Projekt zu erstellen. Unter http://pi.informatik.uni-siegen.de/mitarbeiter/kehrer/lehre/ws09/st1/emf-ueb/ ist ein vordefiniertes Projekt-Gerüst zu finden. In der Klasse test.testdriver ist bereits eine Main- Methode als Einstiegspunkt für Ihre Applikation implementiert. Benötigte Bibliotheken und Projektabhängigkeiten sind bereits in den Java-Klassenpfad des Projekts eingebunden. Beachten Sie, dass es dabei zu Namenskonflikten kommen kann, sollten Sie im ersten Teil dieser Übung von der Musterlösung abweichende Bezeichner verwendet haben. Namenskonflikte können vermieden werden, wenn Sie an dieser Stelle auf der ebenfalls unter http://pi.informatik.uni-siegen.de/mitarbeiter/kehrer/ lehre/ws09/st1/emf-ueb/ zur Verfügung gestellten Musterlösung aufsetzen. Abfrage der ER-Modelldaten Um ein gegebenes ER-Modell, z.b. unser Fussball-ER-Modell, in die entsprechenden Tabellendefinitionen umsetzen zu können, sind die eingelesenen Modelldaten von unserem Übersetzer zu verarbeiten. EMF stellt dabei die Funktionalität zum Einlesen und Parsen der Modelldaten bereits zur Verfügung. Ebenso die Möglichkeit zur Abfrage der Modelldaten. Wir nutzen hier die in der Vorlesung vorgestellte Variante des statischen Zugriffs auf die Modelldaten über die generierten Java-Klassen. Bei der Generierung der Java-Klassen erstellt der EMF Code-Generator für jede Klasse unseres ER-Modell- Datenmodells je ein korrespondierendes Java-Interface sowie eine Java-Klasse, welche dieses Interface
implementiert. Interessant sind an dieser Stelle die Schnittstellendefinitionen. Die konkrete Implementierung sollte im Sinne eines softwaretechnisch sauberen Entwurfs vor dem von uns zu implementierenden Transformator verborgen bleiben. Schauen Sie sich die von EMF generierten Schnittstellen genauer an. Diese stellen eine Reihe von Zugriffsoperationen bereit, welche es uns ermöglichen, die Eigenschaften eines konkreten ER-Modells zu erfragen. Um mit den generierten Datenstrukturen vertraut zu werden ist es hilfreich, zunächst eine Art Report über eingelesene ER-Modelle zu erstellen. Diesen können Sie einfach auf der Konsole ausgeben. Umfassen sollte der Report alle Entitäts- bzw. Beziehungstypen und deren Eigenschaften. Ein Report über das in Schritt 2 erstellte Fussball-ER-Modell könnte also wie folgt aussehen: R e p o r t f o r model : F u s s b a l l =========================== E n t i t y t y p e s : E n t i t y t y p e : name=mannschaft A t t r i b u t e : name=mannschaftsname, t y p e= S t r i n g E n t i t y t y p e : name= S p i e l e r A t t r i b u t e : name=s p i e l e r n a m e, t y p e= S t r i n g E n t i t y t y p e : name= S p i e l A t t r i b u t e : name= k e n n z i f f e r, t y p e=number A t t r i b u t e : name=e r g e b n i s, t y p e= S t r i n g A t t r i b u t e : name= s p i e l t a g, t y p e=date R e l a t i o n t y t y p e s : R e l a t i o n t y p e : name= s p i e l t _ b e i Role : name= s p i e l e r, c a r d i n a l i t y = 1 r e f e r e n c e d E n t i t y t y p e : S p i e l e r Role : name=mannschaft, c a r d i n a l i t y =1 R e l a t i o n t y p e : name= t o r s c h u e t z e Role : name= s p i e l e r, c a r d i n a l i t y = 1 r e f e r e n c e d E n t i t y t y p e : S p i e l e r Role : name= s p i e l, c a r d i n a l i t y = 1 r e f e r e n c e d E n t i t y t y p e : S p i e l R e l a t i o n t y p e : name= s p i e l Role : name= s p i e l, c a r d i n a l i t y =1 r e f e r e n c e d E n t i t y t y p e : S p i e l Role : name=heim, c a r d i n a l i t y =1 Role : name=a u s w a e r t s, c a r d i n a l i t y =1 SQL-Instruktionen zur Tabellendefinition Im letzten Schritt ist der in Prosa gehaltene Report derart zu modifizieren, dass hierbei gültige SQL- Instruktionen zur Definition der gewünschten Tabellen erzeugt werden. Eine Übersicht über die beiden benötigten SQL-Befehle CRATE TABLE (Anlegen einer Tabelle) und ALTER TABLE (Modifikation einer bestehenden Tabelle) finden Sie z.b. unter http://dev.mysql.com/doc/refman/5.1/de/ data-definition.html. Die Abbildungsregeln von ER-Modellen auf Tabellendefinitionen eines RDBMS sind Ihnen aus der Vorlesung bekannt.
Es empfiehlt sich, die Abbildung der ER-Modelle auf die entsprechenden Tabellendefinitionen in zwei Schritte zu untergliedern. Im ersten Schritt werden Tabellendefinitionen für alle Entitätstypen erzeugt. Im zweiten Schritt werden Beziehungstypen umgesetzt, wobei folgende Fälle zu unterscheiden sind: Handelt es sich um einen mehrstelligen Beziehungstyp, so ist eine Verbindungstabelle zu erstellen. Handelt es sich um einen 2-stelligen Beziehungstyp, so ist zu unterscheiden zwischen 1:n- und n:m-beziehungen: n:m-beziehungen müssen ebenfalls über eine Verbindungstabelle abgebildet werden. Die Abbildungsmöglichkeiten für 1:n-Beziehungen (Verbindungstabelle vs. Fremdschlüssel) wurden im Rahmen der Besprechung von Übungsblatt 3 diskutiert.