Entwicklung und Anwendung eines Integrationskonzepts für das Typo3 CMS unter Verwendung von Methoden der Modellgetriebenen Softwareentwicklung

Transkript

1 Freie wissenschaftliche Arbeit zur Erlangung des akademischen Grades Bachelor of Science in Wirtschaftsinformatik Entwicklung und Anwendung eines Integrationskonzepts für das Typo3 CMS unter Verwendung von Methoden der Modellgetriebenen Softwareentwicklung Bachelorthesis im Fachbereich Wirtschaftswissenschaften II im Studiengang Wirtschaftsinformatik der Hochschule für Technik und Wirtschaft Berlin vorgelegt von: Mathias Slawik WEN: Aristotelessteig Berlin Matrikel-Nr.: Erstbetreuer: Prof. Dr. Margret Stanierowski Zweitbetreuer: Prof. Dr. Holger Hemling Abgabetermin:

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Technologieanalyse Begriff: Modellgetriebene Softwareentwicklung Meta-Ebenen Fokus der Technologieanalyse, Einschränkungen MDA Model Driven Architecture MOF Meta Object Facility XMI XML Metadata Interchange EMF - Eclipse Modeling Framework Ecore Ecore Tools und Ecore Diagram Editor openarchitectureware Typ-System oaw-ausdruckssprache (Expression-Language) Xpand Xtend Check Workflow-Engine itemis openarchitectureware Eclipse-Distribution Typo3 CMS Apache Ant Developer Garden Entwicklung eines Typo3 Integrationskonzepts Einleitung Projekt-Verzeichnisstruktur II

3 Inhaltsverzeichnis 3.3 Textuelle Beschreibung Beschreibungen einzelner Funktionalitäten Bereitstellung der Funktionen einer Komponente Backend-Module Versionshistorie Extension-Konfiguration Benutzerdefinierte TS-Funktionen Metamodell Diagramm und Notation EClass Extension EClass ExtensionInformation EClass Module EClass ModuleFunction EClass Library EClass LibraryFunction EClass LibraryFunctionSignature EClass LibraryFunctionParameter EClass LibraryFunctionReturn EClass Configuration EClass ConfigurationField EClass Author EClass Versions EClass Version EClass UserFunction EEnum Categories EEnum State EEnum LockType III

4 Inhaltsverzeichnis 3.6 Extensions Code-Templates oaw Workflow Build-Datei Anwendung des Typo3 Integrationskonzepts Modellinstanz Generierung des Prototyps Nachweis der Funktionsfähigkeit Fazit IV

5 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1 - Ecore-Metametamodell Basiselemente... 7 Abbildung 2 - Aufbau des Typo3 CMS Abbildung 3 - Diagramm des Extension-Metamodells Abbildung 4 - Extension-Informationen der tt_news - Extension im TER Abbildung 5 - Extension-Informationen der tt_news - Extension im EM (Ausschnitt) 35 Abbildung 6 - Importierte, leere Projektverzeichnis-Struktur Abbildung 7 - Geöffnetes Typo3 Extension-Metamodell Abbildung 8 - Instanziierung der Extension Abbildung 9 - Bearbeitung der Metamodell-Instanz Abbildung 10 - Hinzugefügte manuelle Artefakte Abbildung 11 - Konfiguration der Build-Datei Abbildung 12 - Eclipse-Umgebung nach Generierung der Extension Abbildung 13 - Typo3 EM bietet Developer Garden Extension zur Installation an Abbildung 14 - Pflege der Developer Garden Zugangsdaten über den Typo3 EM Abbildung 15 - Extension-Modul bietet Bibliotheksfunktionen zur Ausführung an Abbildung 16 - Antwort-Objekt quittiert erfolgreichen Versand einer Test-SMS Abbildung 17 - Empfang der Test-SMS auf dem Mobiltelefon Abbildung 18 - Anzeige der Ausgabe einer benutzerdefinierten TS-Funktion V

6 Einleitung 1 Einleitung Diese Arbeit soll auf Basis von Methoden der Modellgetriebenen Softwareentwicklung ein Konzept entwickeln und anwenden, welches es ermöglicht, unterschiedliche Software-Komponenten in das Typo3 CMS zu integrieren. Alle für die Entwicklung des Konzepts notwendigen theoretischen und technologischen Grundlagen werden am Anfang der Arbeit analysiert. Auf Basis dieser Analyse wird ein Integrationskonzept abgeleitet und erläutert. Die Vollständigkeit des Integrationskonzepts wird durch die Funktionsfähigkeit einer dadurch generierten Erweiterung bewiesen. Zentraler Aspekt dieses Integrationskonzepts ist die Modellierung eines formalen Metamodells für Typo3 Erweiterungen. Die für dieses Metamodell entwickelten Templates führen dazu, dass fast alle Artefakte einer Typo3 Erweiterung aus einer Modellinstanz generiert werden können. Die mit Hilfe des Integrationskonzepts generierte Erweiterung ermöglicht die Nutzung des PHP SDKs des Entwicklerportals Developer Garden durch das Typo3 CMS. Dadurch wird die potenzielle Nutzerbasis des Developer Gardens deutlich erhöht. Außerdem werden, gegenüber der manuellen Implementierung, durch die Generierung Entwicklungskosten gespart. Diese Auswirkungen stellen einen erheblichen betriebswirtschaftlichen Nutzen für den Praxispartner, die Deutsche Telekom AG, dar. Diese Arbeit soll folglich neben den konzeptionellen Aspekten ein praxisbezogenes Ergebnis erzielen, welches anwendbar und qualitativ hochwertig ist und auch in Zukunft Bestand haben wird. 1

7 Technologieanalyse 2 Technologieanalyse Dieses Kapitel soll technologische, methodische und theoretische Grundlagen analysieren, sodass darauf aufbauend ein Integrationskonzept abgeleitet werden kann. Diese Zielsetzung bedingt eine Beschränkung des Umfangs der Analyse auf die für die spätere Ableitung hinreichend notwendigen Aspekte der zugrunde liegenden Technologien. 2.1 Begriff: Modellgetriebene Softwareentwicklung Modellgetriebene Methoden der Softwareentwicklung und des Softwaredesigns (MDSD bzw. MDD) 1 stellen eine Erweiterung von modellbasierten Methoden dar. 2 Die modellbasierte Softwareentwicklung nutzt in der Regel eine Modellierungssprache (z.b. die UML) um unterschiedliche Aspekte eines Softwaresystems darzustellen. Dies geht meist einher mit der Verwendung des Modells als Dokumentation des Softwaresystems ein Sachverhalt, der einige Probleme mit sich bringt: Zum einen ist Software, insbesondere am Anfang ihres Lebenszyklus meist starken Änderungen unterworfen, was die Pflege des Modells aufwändig macht oder zu Inkonsistenzen zwischen Code und Modell führt, falls das Modell nicht oder nur ungenügend gepflegt wird. Auf der anderen Seite betrachten viele Programmierer die entstehenden Modelle als Overhead, da die Pflege der Modelle nur mittelbar zu einem Fortschritt des Projekts führt, da ja erst durch ihre Interpretation Code entsteht. 3 Das Ziel von modellgetriebener Softwareentwicklung ist es, domänenspezifische daher auf einen fachlichen Geltungsbereich beschränkte Abstraktionen zu finden und diese in einer formalen Modellierung zugänglich zu machen. 4 Weiterhin sollen auf Basis dieser Modelle möglichst viele Artefakte eines Softwaresystems generativ abgeleitet werden 5. 1 (Beltran, et al., 2007 S. 12) 2 (Stahl, et al., 2007 S. 3) 3 (Stahl, et al., 2007 S. 3) 4 (Stahl, et al., 2007 S. 4) 5 (Beltran, et al., 2007 S. 11) 2

8 Technologieanalyse Für die Umsetzung dieses Konzepts werden daher folgende Dinge benötigt: Domänenspezifische Sprachen zur Formulierung der Modelle Generatoren, Transformatoren und Interpreter, um die Modelle in Programmcode zu überführen Die Generierung des auf der Zielplattform lauffähigen Codes aus dem Modell bringt mit sich, dass in der modellgetriebenen Softwareentwicklung die Modelle nicht als Dokumentation, sondern ähnlich wie Programmcode betrachtet werden müssen. Modelle nehmen also bei modellgetriebener Softwareentwicklung also eine zentrale Rolle ein, da sie nicht nur als Dokumentation, sondern da aus Ihnen die ausführbare Anwendung erzeugt wird Meta-Ebenen Der Begriff Meta- beschreibt die Beziehung zwischen zwei Modellen bzw. Ebenen. 7 Die OMG formalisiert diesen Sachverhalt in Ihren Veröffentlichungen durch die Definition von vier Metaebenen 8 : Metaebene Beispiele Rolle M3 - Meta-Metamodell MOF und Untermengen (CMOF, EMOF), ECore Definiert formale Syntax und Semantik für Metamodelle M2 Metamodell Typo3-Extension Metamodell, UML, CWM M1 Modell Developer Garden Typo3- Extension, UML-Modelle M0 - Ausführbarer Code.NET, Java- oder PHP- Applikationen. Instanziiert Elemente des Meta- Metamodells. Definiert formale Syntax und Semantik für Modelle. Instanziiert Elemente des Metamodells. Legt fest, in welcher Form das Modell durch die M0-Ebene instanziiert werden soll. Laufzeit-Instanz des Modells 6 (Beltran, et al., 2007 S. 12) 7 (Stahl, et al., 2007 S. 62) 8 (Object Management Group, 2009B S ) 3

9 Technologieanalyse 2.3 Fokus der Technologieanalyse, Einschränkungen Die Implikationen der modellgetriebenen Softwareentwicklung auf den Softwareentwicklungsprozess sind mannigfaltig. Diese in Ihrer Gänze zu beschreiben, würde den Umfang dieser Arbeit weit übersteigen. Daher wurden folgende Gesichtspunkte der modellgetriebenen Softwareentwicklung ausgewählt, um an Ihnen exemplarisch die Implikationen der Methode darzustellen: Verwendung eines formalen Modells zur Beschreibung des fachlichen Geltungsbereiches der durch das Integrationskonzept zu erstellenden Software. Für den Geltungsbereich Typo3 Extension wird ein formales Metamodell erstellt, welches diesen fachlichen Geltungsbereich einschränkt und definiert. Auf Grundlage dieses Metamodells wird ein Modell instanziiert, welches die Basis der zu erstellenden Software bildet. Dabei wird das Modell nicht nur die Rolle der Dokumentation spielen, wie es z.b. bei modellbasierter Entwicklung auf Basis der UML meistens der Fall ist. Im Gegenteil das Modell wird die Basis der Software darstellen ähnlich der herkömmlichen Rolle des Programmcodes. Erzeugung von lauffähiger, fehlerfreier, performanter und vollständiger Software Der Unterschied zwischen Theorie und Praxis ist in der Praxis weit höher als in der Theorie. 9 Es soll gezeigt werden, dass eine praktische Ausarbeitung der theoretischen Grundlagen modellgetriebener Entwicklung sehr wohl in der Lage ist gute, d.h. lauffähige, fehlerfreie, performante und vollständige Software zu erzeugen. Automatisierung Bei der gesamten praktischen Ausarbeitung soll gezeigt werden, wie durch die Methode der modellgetriebenen Entwicklung eine erhebliche Automatisierung großer Teile der Softwareentwicklung vonstatten gehen kann. 9 (Ferstl, 1996) 4

10 Technologieanalyse 2.4 MDA Model Driven Architecture Die MDA (Model Driven Architecture) ist eine Standardisierungsinitiative der OMG (Object Management Group). Zielsetzung ist es, Richtlinien und Standards zur Verfügung zu stellen, die Interoperabilität und Portabilität von Softwaresystemen im Kontext modellgetriebener Entwicklung ermöglichen. Die zur Verfügung gestellten Richtlinien und Standards sollen eine Strukturierung von Spezifikationen in Form von Modellen gestatten. 10 Die MDA legt fest, dass eine zu ihr kompatible Spezifikation eines Softwaresystems sich in ein plattformunabhängiges und ein oder mehrere plattformabhängige Modelle aufteilen muss. 11 Das plattformunabhängige Modell (platform-independent model / PIM) enthält die Bestandteile, die sich nicht auf eine konkrete Implementierung beziehen, also zum Beispiel die Geschäftslogik oder das Verhalten der Applikation. Die plattformabhängigen Modelle (Platform Specific Model / PSM) enthalten die Implementationsspezifika des PIM, also z.b. JavaBeans, Datenbanktabellen oder Webservices. Darüber hinaus kann eine umgangssprachliche Beschreibung (Computation Independent Model / CIM) des Softwaresystems definiert werden. Dieses Vorgehen soll unter anderem den Anpassungsaufwand des Softwaresystems an neue Technologien vereinfachen und eine Plattform-, Sprach- und Systemunabhängigkeit anstreben. 2.5 MOF Meta Object Facility Die MOF (Meta Object Facility) ist Kernbestandteil der MDA. MOF beschreibt das Metamodell, welches Grundlage von MDA-basierten Tools ist bzw. sein sollte. 12 Die Definition von PIM, PSM und CIM soll daher formal in MOF definiert sein. Die UML verwendet in ihrer Definition das Metamodell der MOF (Stahl, et al., 2007 S. 377) 11 (Object Management Group, 2009A) 12 (Stahl, et al., 2007 S. 379) 13 (Object Management Group, 2009 S. 14) 5

11 Technologieanalyse 2.6 XMI XML Metadata Interchange XMI ist ein auf XML basierendes Format für MOF-Modelle und ermöglicht dadurch die Speicherung und den Austausch von MOF-Modellen, auch zwischen verschiedenen MOF-Tools EMF - Eclipse Modeling Framework Das Eclipse Modeling Framework ist eine Basistechnologie, mit der Metamodelle definiert werden können 15 und ist gleichzeitig die de-facto Referenzimplementierung der MOF. 16 Das EMF zugrunde liegende Metamodell Ecore lehnt sich stark einer Untermenge von MOF, dem Essential MOF (EMOF) an. 17 Das EMF unterstützt in XMI serialisierte EMOF und Ecore Modelle und darüber hinaus auch weitere Importformate, wie z.b. XML Schemas (XSD). 18 Neben der Definition eigener Metamodelle können mit Hilfe von EMF unter anderem BPNM und UML2- Modelle verarbeitet werden. 19 Da das EMF die Definition eigener Metamodelle zulässt, steht es dem Nutzer frei, ob eine Aufteilung des Softwaremodells in PIM, PSM und CIM erfolgt, oder eine eigene Systematik angewendet wird. Darüber hinaus kann das EMF aus Ecore Modellen folgende Code-Artefakte erzeugen: Java-Modell Das generierte Java-Modell enthält Java-Interfaces und Java-Klassen für alle Metaklassen des Metamodells. Bei manueller Bearbeitung der generierten Java-Klassen kann durch Java-Annotations festgelegt werden, dass diese Bearbeitungen bei der nächsten Generierung nicht überschrieben werden. 14 (Object Management Group, 2007) 15 (Stahl, et al., 2007 S. 71) 16 (Efftinge, et al., 2009) 17 (Gronback, 2009 S. 663) 18 (Gronback, 2009 S. 664) 19 (Gronback, 2009 S. 665, 663) 6

12 Technologieanalyse Adapterklassen Adapterklassen (sogenannte ItemProviders) ermöglichen die Anzeige und Bearbeitung der Klassen des Metamodells unter Verwendung von Steuerelementen (Textboxen, Radio-Buttons, etc.) der Eclipse IDE. Editor Unterstützt die Generierung eines Editors, welcher den Empfehlungen für Eclipse EMF Modelleditoren folgt. Dieser generierte Editor dient normalerweise als Ausgangspunkt für durch den Benutzer angepasste Editoren. 2.8 Ecore Ecore ist das dem EMF zugrunde liegende Metametamodell. Folgende Abbildung zeigt die Ecore-Basiselemente: esupertypes 0..* EClass name : String estructuralfeatures 0..* EStructuralFeature name : String ereferencetype 1 EReference containment : boolean lowerbound : int upperbound : int EDat atype name : String eopposite 0..1 eattributetype 1 EAttribute Abbildung 1 - Ecore-Metametamodell Basiselemente Aus (Steinberg, 2008 S. 19) 7

13 Technologieanalyse Die semantische Bedeutung der Basiselemente lautet wie folgt: EClass Eine EClass abstrahiert eine Metamodellklasse. Sie enthält eine beliebige Anzahl von Eigenschaften (estructuralfeatures) und kann selbst von beliebig vielen anderen EClasses erben (esupertypes). EStructuralFeature Ein EStructuralFeature ist eine Eigenschaft einer Metamodellklasse. Sie kann entweder eine Referenz (EReference) oder ein Attribut (EAttribute) sein. EReference Eine EReference ist eine Referenz einer Metamodellklasse auf eine andere. Die Parameter lowerbound und upperbound legen die Unter- und Obergrenze der Anzahl an referenzierten Elementen fest. Eine EReference kann eine Referenz auf eine andere EReference enthalten (eopposite). Dadurch wird eine bidirektionale Verknüpfung realisiert. Ist dies nicht der Fall, so enthält die referenzierte EClass keine Weiterhin kann eine EReference ein Kompositionsverhältnis (Containment) darstellen. Ob dies der Fall ist, wird durch containment festgelegt. EAttribute Ein EAttribute ist ein Attribut einer Metamodellklasse. Es ist immer einem Datentyp zugeordnet. EDataType Ein EDataType referenziert einen Datentyp eines Attributs. Es existieren diverse Datentypen (z.b. Zeichenketten, Ganzzahl-Werte, Listen, etc.), die jeweils einer Java-Klasse zugeordnet sind. 21 Über diese Basiselemente hinaus existieren noch weitere Ecore- Metametamodellelemente. 22 Diese sind für das spätere Metamodell überwiegend nicht relevant und werden daher hier nicht gesondert aufgeführt. 21 (IBM Corporation, 2006) 22 (IBM Corporation, 2006) 8

14 Technologieanalyse Als einziges weiteres Element sei hier EEnum erwähnt, welches einen typischen Java-Enum abstrahiert Ecore Tools und Ecore Diagram Editor Die Ecore Tools sind eine Komponente des Eclipse Modeling Framework Technology (EMFT) Projekts. Das EMFT-Projekt hat sich als Aufgabe gesetzt, neue Technologien zur Erweiterung oder Ergänzung von EMF zu erzeugen. 24 Ein bedeutender Bestandteil der Ecore Tools ist der Ecore Diagram Editor, welcher die Pflege eines Ecore-Modells in Form eines Diagramms ermöglicht. 25 Änderungen im Diagramm können auf Wunsch automatisch in das Ecore- Metamodell übertragen werden. Darüber hinaus besteht ebenso die Möglichkeit, Diagramme zu erstellen, welche lediglich ausgewählte Metamodellelemente enthalten. 2.9 openarchitectureware 4 openarchitectureware 4 (oaw) ist eine in Java implementierte, quelloffene MDSD Plattform auf Basis des EMF. 26 Ihre einzelnen Bestandteile werden in den folgenden Unterkapiteln erläutert Typ-System Das Typ-System bildet die Grundlage der weiteren Bestandteile der oaw-plattform. Es definiert für die Verarbeitung gemeinsamer Datenstrukturen, z.b. Zeichenketten, Listen oder Ganzzahlen der unterschiedlichen Metametamodelle, z.b. Ecore, XSD oder JavaBeans gemeinsame oaw-typen oaw-ausdruckssprache (Expression-Language) Die oaw-ausdruckssprache definiert Syntax und Semantik einer eigenen Sprache innerhalb des oaw-typ-systems. 28 Sie lehnt sich syntaktisch an Java und die von der OMG definierte Object Constraints Language (OCL) an. Sie wird in allen textuellen Bestandteilen von oaw, also Xtend, Xpand2 und Check verwendet. 23 (Sun Microsystems, Inc., 2008) 24 (The Eclipse Foundation, 2009) 25 (Sciamma, 2007) 26 (Efftinge, 2009) 27 (Efftinge, et al., 2008 S. 53) 28 (Efftinge, et al., 2008 S. 58) 9

15 Technologieanalyse Xpand2 Xpand2 ist eine Sprache, mit derer Vorlagen (Templates) für Modell zu Text Transformationen definiert werden können Xtend Xtend ist eine funktionale Sprache, mit der nicht-invasive Erweiterungen von Metametamodellen und deren Elemente definiert werden können. 30 Diese Erweiterungen werden entweder unter Verwendung der Expression-Language oder mit Hilfe von Java-Methoden implementiert. Durch Xtend sind darüber hinaus auch Modell zu Modell-Transformationen möglich. Der übliche Anwendungsbereich von Xtend ist die Kapselung von wiederkehrenden und komplexen Formulierungen für die Verwendung in Xpand2-Templates Check Check ist eine Sprache, mit der Bedingungen (Constraints) für das jeweilige Metamodell festgelegt werden können, unter denen es als gültig betrachtet wird. 32 Die Bedingungen werden dabei in der oaw-ausdruckssprache definiert Workflow-Engine Die openarchitectureware Workflow-Engine ermöglicht es, auf Basis von XML- Konfigurationsdateien unterschiedliche Generator-Workflows zu definieren. 33 Ein Generator-Workflow besteht aus mehreren Workflow-Komponenten, die in einer gemeinsamen JVM zur Ausführung gebracht werden. Workflow-Komponenten sind üblicherweise Komponenten zum Einlesen und Überprüfen von Modellen und zur Generierung von Code. Die Komponenten können untereinander Daten austauschen, indem sie Schreiboder Lesezugriffe auf sogenannte Slots durchführen. Diese Slots erfüllen in oaw eine gleiche Funktion, wie einfache Variablen. Slots müssen nicht deklariert werden und werden über ihren Namen identifiziert. 29 (Efftinge, et al., 2008 S. 77) 30 (Efftinge, et al., 2008 S. 66) 31 (Beltran, et al., 2007 S. 197) 32 (Efftinge, et al., 2008 S. 65) 33 (Efftinge, et al., 2008 S. 42) 10

16 Technologieanalyse Die openarchitectureware Workflow-Engine lässt sich darüber hinaus auch über Apache Ant aufrufen 34. Dies erhöht die Möglichkeiten zur Automatisierung deutlich und findet auch in dieser Arbeit Verwendung itemis openarchitectureware Eclipse-Distribution Die quelloffene itemis openarchitectureware Eclipse-Distribution 35 wird von der itemis AG bereitgestellt und enthält eine bereits vorkonfigurierte Eclipse IDE, welche viele Komponenten für modellgetriebene Entwicklung, unter anderem EMF und oaw bereithält. Die in dieser Arbeit beschriebene Entwicklung erfolgte ausschließlich mit Hilfe dieser Distribution Typo3 CMS Typo3 ist ein quelloffenes, unter der GPL stehendes, webbasiertes Content Management System. 36 Es basiert auf der Programmiersprache PHP, verwendet MySQL als Standard-DBMS und wird vorwiegend unter Linux-Systemen auf dem Apache HTTP-Server betrieben. 37 Ein Merkmal des Systems ist seine Erweiterbarkeit, die sich in über 3000 Erweiterungen (sog. Extensions ) manifestiert Siehe 2.11 (S. 15) 35 (itemis AG, 2009) 36 (Stöckl, et al., 2009 S. 26) 37 (Stöckl, et al., 2009 S. 29) 38 (Typo3 Association, 2009A) 11

17 Technologieanalyse Folgende Grafik zeigt eine Übersicht des Typo3 CMS: Website Frontend Seiteninhalte werden unter Verwendung von Templates und Extensions dargestellt. Backend Administration geschieht durch Core-Funktionen und Extensions. Einheitliches Interface Obwohl Typo3 aus vielen einzelnen Extensions besteht, wirkt das Gesamtsystem einheitlich. Administration Extensions Klar getrennte Code-Ergänzungen, beigesteuert und unterstützt von Mitgliedern der Community. TYPO3 Extension API Core Kontrolle und Entwicklung durch die Typo3 Core Group. Typo3 CORE Authentifizierung, Datenbankzugriff, Visuelles Interface, Framework, Installation, Konfiguration, etc. System (PHP, Apache, MySQL) Abbildung 2 - Aufbau des Typo3 CMS Angelehnt an (Typo3 Association, 2009H) 12

18 Technologieanalyse Nachfolgend werden einige Begriffe im Kontext des Typo3-CMS erläutert: 1. Frontend Das Typo3 Frontend bezeichnet den Teil des Typo3 CMS, der für die Präsentation von Inhalten zuständig ist. Das Frontend nutzt Vorlagen (sog. Templates) für die Formatierung der Inhalte und stellt diese in unterschiedlichen Formaten bereit, u.a. HTML, XHTML oder XML. 2. Backend Das Typo3 Backend ist für die übergreifenden Administrationsfunktionen zuständig, unter anderem: Verwaltung von Inhalten Authentifizierung der Benutzer Kapselung des Datenbankzugriffs Bereitstellung der Typo3 Extension / Core API Installation und Konfiguration des Typo3 CMS 3. Backend-Module Backend-Module sind Gruppierungen von Backend- Administrationsfunktionen, beispielsweise Funktionen für die Pflege von Inhalten (Erstellen, Ändern, Löschen, Freigeben, Hochladen, etc.), die Bearbeitung von Benutzerrechten oder die Installation von Extensions 4. TypoScript TypoScript ist eine deklarative Sprache zur Steuerung des Verhaltens des Typo3 CMS. 40 Es wird bei der Definition von Templates und der Seiten- und Benutzereinstellungen (sog. User- und Page TS-Config) verwendet. 5. Typo3 Extensions Eine Typo3-Extension ist eine Erweiterung des Typo3-Core um beliebige Funktionalität. Eine Extension kann PHP-Code, TypoScript und SQL-Anweisungen enthalten. Der Typo3-Core definiert die Extension API, durch die Typo3 Extensions die Typo3 Backend- und Frontend-Funktionen nutzen können. 40 (Stöckl, et al., 2009 S. 431) 13

19 Technologieanalyse Dateinamen- und Verzeichniskonventionen führen zu einem einheitlichen Aufbau von Typo3 Extensions. Eine Extension wird über einen global eindeutigen Schlüssel identifiziert, den sogenannten Extension-Key. 6. Typo3 Extension Manager (EM) Der Typo3 Extension Manager ist ein Typo3 Backend-Modul, welches umfangreiche Verwaltungsfunktionen für Extensions realisiert. Er ist mit Paketverwaltungssystemen, wie Ruby GEM 41, Perl CPAN 42, Debian DPKG/APT 43 vergleichbar und unter anderem zuständig für Installation und Deinstallation, Abhängigkeitsbehandlung und Konfiguration von Extensions. 7. Typo3 Extension Repository (TER) Das Typo3 Extension Repository ist ein zentrales Verzeichnis von Typo3 Extensions. 44 Der EM kann Extensions aus dem TER herunterladen und in das TER hochladen. 8. Typo3 Extension Kickstarter Der Typo3 Extension Kickstarter ist eine Extension zur Generierung einer Vorlage für eine neue Extension auf Basis von gewünschten Funktionalitäten. Derzeit wird empfohlen, eine Typo3 Extension durch die Implementierung einer durch den Kickstarter generierten Vorlage zu erstellen. 45 Der Extension Kickstarter besitzt allerdings bis auf die Bearbeitung des PHP- Quelltextes keine Möglichkeit, die Codevorlagen oder das der Generierung zugrunde liegende Modell zu ändern. Darüber hinaus nutzt der Kickstarter keine formalen Beschreibungen für seine Arbeitsweise und die implementierten Klassen werden bei jeder Generierung überschrieben. Somit existieren einige Schwachpunkte, die durch ein Integrationskonzept auf Basis von Methoden der modellgetriebenen Entwicklung behoben werden können. 41 Siehe (Ruby Central, Inc., 2009) 42 Siehe (Hietaniemi, 2001) 43 Siehe (Aoki, et al., 2008) 44 (Typo3 Association, 2009G) 45 (Typo3 Association, 2009F) 14

20 Technologieanalyse 2.11 Apache Ant Apache Ant ist ein sogenanntes Build Tool, ein Werkzeug zum automatisierten Erzeugen von Artefakten. Ant wurde entwickelt, um den Erstellungsprozess von Java- Anwendungsprogrammen zu automatisieren 46 und ist im Funktionsumfang vergleichbar mit dem standardisierten Unix-Tool make 47. Ant wird durch sogenannte Build-Files gesteuert. Dies sind XML-Dateien welche die für einen Erstellungsprozess notwendigen Schritte enthalten. Diese Schritte können durch Abhängigkeitsbeziehungen verknüpft werden und sind selbst in Java implementiert. Dadurch ist Ant plattformunabhängig und erweiterbar Developer Garden Der Developer Garden ist das Entwicklerportal der Deutschen Telekom AG. 48 Es bietet Webservices, über die eine Nutzung von Diensten der Deutschen Telekom AG ermöglicht wird. Das Portal bietet die folgenden Dienste: Voice Call Herstellen von Telefonverbindungen Send SMS Versand von Kurznachrichten Local Search Internet-Suchabfragen IP Location Lokationsabfrage von T-Online-Nutzern Conference Call Herstellen von Telefon-Konferenzen Für die Nutzung der Schnittstellen stehen SDKs in den Programmiersprachen Java, PHP und Ruby, sowie für die.net-plattform bereit. 49 Die Webservice-Schnittstellen unterstützen das SOAP-Protokoll 50 und werden über die WSDL 51 beschrieben. 46 (The Apache Ant Project, 2009) 47 (The Open Group, 2004) 48 (developer garden, 2009C) 49 (developer garden, 2009B) 50 (W3C, 2007) 51 (W3C, 2001) 15

21 Technologieanalyse Die APIs der Webservice-Schnittstellen, sowie der SDKs ist fachlich getrieben. 52 Dies bedeutet, dass es für jeden atomaren Vorgang, der durch die Webservice- Schnittstelle angeboten wird, genau eine Funktion bzw. Methode gibt, um diesen auszuführen. 53 Die vier SDKs besitzen eine sehr ähnliche API und unterscheiden sich nur in den Namenskonventionen und einigen plattformspezifischen Eigenheiten. Beispielsweise wird im PHP-SDK die Syntax für optionale Funktionsparameter 54 verwendet eine Funktionalität, die in den anderen Programmiersprachen nicht vorgesehen ist. Ein weiteres Beispiel ist die Verwendung von Eigenschaften 55 im.net-sdk eine Funktionalität, die in den anderen Sprachen über Abfrage und Änderungsmethoden umgesetzt wird. Der Aufruf einer Webservice-Methode verläuft unter Nutzung der SDKs immer in zwei Schritten: 1. Instanziierung des jeweiligen Service-Client Objekts In allen drei SDKs steht für jeden angebotenen Dienst eine Client-Klasse zur Verfügung. Die Benennung ist intuitiv gewählt - beispielsweise lautet die Client-Klasse für den Voice Call-Dienst VoiceCallClient, die für den Send SMS- Dienst SmsClient. Die Parameter des jeweiligen Konstruktors sind immer die Developer Garden Zugangsdaten, anhand derer bei einer Instanziierung versucht wird, eine Authentifikation durchzuführen. 2. Aufruf der Service Methode Konnte die bei der Instanziierung der Service-Clients durchgeführte Authentifikation erfolgreich durchgeführt werden, so können die Webservice- Methoden des Dienstes über einen Methodenaufruf des Service-Client Objekts aufgerufen werden. 52 Vgl. (Josuttis, 2008 S. 36) 53 Vgl. (developer garden, 2009A) 54 Siehe (The PHP Group) 55 Siehe (Microsoft Developer Network, 2009) 16

22 Technologieanalyse Verläuft der Webservice-Aufruf erfolgreich, so liefert die Service-Client- Methode ein Antwortobjekt zurück, welches die Rückgabewerte des Webservices kapselt. 17

23 Entwicklung eines Typo3 Integrationskonzepts 3 Entwicklung eines Typo3 Integrationskonzepts In diesem Kapitel wird auf Grundlage der Technologieanalyse ein Typo3- Integrationskonzept abgeleitet und beschrieben. 3.1 Einleitung Hintergrund der Notwendigkeit der Entwicklung eines Integrationskonzepts war der Entschluss der Deutschen Telekom, das vorhandene Developer Garden PHP SDK auch für Typo3-Entwickler zur Verfügung zu stellen. Dabei sollten die Besonderheiten des Typo3 CMS Berücksichtigung finden, so dass durch eine vereinfachte Nutzung der PHP SDKs unter Typo3 ein Anreiz für Typo3-Entwickler entsteht, die Developer Garden Dienste zu nutzen. Um diesen Entschluss umzusetzen sollte eine Extension entwickelt werden, die einerseits die Typo3-Core-Funktionalität in sinnvoller Weise nutzt, als auch dem Programmierer die gleiche fachlich getriebene API anbietet, wie sie durch das PHP-SDK angeboten wird. Da die Entwicklung der Extension meine Aufgabe war, war es mir möglich, die Entwicklungsmethode frei zu wählen. Aufgrund der Vorteile, die ich in der modellgetriebenen Softwareentwicklung gesehen habe, wählte ich diese aus, um die Extension zu entwickeln. Die Ausarbeitung der Bachelorarbeit erlaubt eine höhere Abstraktionsebene als lediglich die Implementierung einer Extension, sodass einerseits der Entschluss der Telekom umgesetzt werden kann, andererseits auch ein generelles Typo3- Integrationskonzept abgeleitet wird. Ziel dieses Konzepts ist daher die Beschreibung eines möglichen Vorgehens zur Integration verschiedenartiger Komponenten in das Typo3 CMS. 18