Identifikation und Optimierung von Komponentenstrukturen in UML-Modellen

Transkript

1 Diplomarbeit Identifikation und Optimierung von Komponentenstrukturen in UML-Modellen 31. Mai 2008 Bearbeitet von: Eraste Waffo Wambou Betreut von: Erstgutachter: Prof. Dr. Andreas Rausch Zweitgutachter: Prof. Dr.Sven Hartmann Betreuer: Constanze Deiters, Sebastian Herold Institut für Informatik, Abt. Software Systems Engineering an der TU-Clausthal.

2 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Clausthal,

3 Danksagung Mein besonderer Dank an dieser Stelle gilt an meiner Frau und meiner Tochter, die mich während des Studiums immer unterstutzt haben. Auch möchte ich Herr Sebastian Herold, Frau Constanze Deiters und Herr Prof. Dr. Andreas Rausch danken, die diese Arbeit ermöglicht haben und zu ihrem Gelingen beigetragen haben. Auch danke ich ganz herzlich allen Korrekturlesern für ihre Mühen. Dies gilt besonders für Avelina und Mathias Eichler, die nicht mühe wurden, die Diplomarbeit immer und immer wieder zu lesen und nach Fehlern zu suchen. Abschließend möchte ich mich besonders bei meiner Eltern und Schwieger Eltern bedanken, die mich immer aufgebaut haben, wenn keine Mut mehr hatte. 3

4 Kurzfassung Komplexität. Dies stellt heutzutage neben den rapiden technischen Veränderungen die größte Herausforderung dar, vor der die Softwareentwicklung steht. Daher werden bei Softwareentwicklungsprozessen Ziele wie Übersichtlichkeit, Stabilität, Sicherheit, Flexibilität und hohe Wiederverwendung angestrebt. Da Informations- und Kommunikationstechnologien als entscheidende Erfolgs- und Wettbewerbsfaktoren für Unternehmen im Mittelpunkt stehen, wird die Forderung nach effizienten, zeitsparenden und kostengünstigen Entwicklungsprozessen immer lauter. Viele Unternehmen allerdings nutzen Systeme, in denen eine Vielzahl von Klassen und Service- Methoden unstrukturiert nebeneinander existieren. Dieser Mangel an Struktur hat einerseits Auswirkungen auf die Effizienz des Systems, andererseits erschwert er eine zeit- und kostengünstige Erweiterung des Systems, Wartungen oder Anpassungen an technische Veränderungen. Mitunter wird all dies sogar als unmöglich eingestuft und eine komplette Neuprogrammierung ins Auge gefasst, die wiederum langwierig und teuer ist. Zur Bewältigung der Komplexität von IT-Lösungen hat sich das Zusammenfassen von Klassen in Pakete und von Service-Methoden in Komponenten als überaus hilfreich erwiesen, was sowohl bei der Softwareentwicklung als auch bei der Strukturierung bestehender Systeme vorgenommen werden kann. Diese Arbeit entsteht im Rahmen eines Forschungsprojektes des Lehrstuhls für Software Systems Engineering der TU Clausthal, dessen Ziel es ist, ein Verfahren zur Identifikation und Optimierung von Komponentenstrukturen zu entwickeln. Es gilt, einen Prototyp zu entwerfen, der in Form eines Eclipse PlugIns zu einer Verbesserung der Komponentenstruktur eines Systems führt. Dieses Verfahren bildet aus Service-Methoden je nach Grad ihrer Ähnlichkeit zueinander Komponenten. Die Schwierigkeit bei der Bildung von Komponenten besteht darin, einerseits Gruppen von Service-Methoden zu bilden, die von ihrer Umwelt möglichst unabhängig sind (lose Kopplung). Andererseits sollten nur solche Service-Methoden zu einer Komponente zusammengefasst werden, die möglichst viel miteinander zu tun haben (hohe interne Kohäsion). Das hier vorgestellte Verfahren ermöglicht es, Service-Methoden zu Komponenten zusammenzufassen und die so entstandene Komponentenstruktur über Algorithmen - unter Einbeziehung dieser beiden gegensätzlichen Anforderungen, der losen Kopplung und der hohen internen Kohäsion - weiter zu verbessern. 4

5 Inhaltsverzeichnis Eidesstattliche Erklärung... 2 Danksagung... 3 Kurzfassung... 4 Inhaltsverzeichnis Einleitung Aufgabenstellung und Zielsetzung Aufbau der Arbeit Grundlagen Modellgetriebene Softwareentwicklung Probleme der heutigen Softwareentwicklungsprozesse Model Driven Architecture Der verwendete Entwicklungsprozess UML Diagrammtypen Technologie Zielarchitektur Schichtenarchitektur Komponenten Serviceorientierte Anwendungsschnittstelle Beispielanwendung: Bibliothek Beschreibung der Beispielanwendung Modellierung der Beispielanwendung Analysemodell Entwurfsmodell Verfahren Identifikation von Komponenten Ähnlichkeitsanalyse Clustering Abbildung von Clustern auf Komponenten Optimierung der Komponentenstruktur Softwaremaße, Metriken Optimierung der Komponenten Vorschlag zur Verbesserung des Verfahrens Implementierung und Design Systemüberblick Komponenten bilden Modell laden LCOM-Wert berechnen Komponenten zusammenlegen Klassendiagramm Beispiel Komponenten bilden Model Editor LCOM-Wert berechnen

6 5.2.4 Komponenten zusammenlegen Zusammenfassung und Ausblick Zusammenfassung Ausblick Anhang Literaturverzeichnis Abbildungsverzeichnis

7 1. Einleitung 1. Einleitung Heutzutage sieht sich die Softwareentwicklung mit immer größer und komplexer werdenden Systemen konfrontiert; man denke beispielsweise an Online-Bestellsysteme wie Ebay oder an Steuerungssysteme in Fahrzeugen. Mit der Entwicklung der objektorientierten Programmierung versuchte man, die Komplexität der Softwareentwicklungsprozesse in den Griff zu bekommen. Ziel war und ist es, Software zu entwickeln, die übersichtlich aufgebaut ist, stabil und sicher läuft, Flexibilität gegenüber Änderungen beweist, möglichst keine Redundanzen aufweist und dadurch einen hohen Grad an Wiederverwendung erreicht. Trotz allem bleibt die Entwicklung hochwertiger Software immer noch sehr aufwändig. Eine weitere Herausforderung, mit der die Softwareentwicklung und vor allem die Softwareentwickler(innen) konfrontiert sind, ist die rasante Verbreitung und Nutzung von Softwaresystemen. Die Gesellschaft befindet sich gegenwärtig in einem Wandel von einer Industrie- zu einer Informationsgesellschaft, in der die Informations- und Kommunikationstechnologien als entscheidende Erfolgs- und Wettbewerbsfaktoren für Unternehmen im Mittelpunkt stehen. Die Informationstechnologie wird zunehmend nicht nur als Werkzeug angesehen, das die Umsetzung der Unternehmensziele unterstützt, sondern ist ein integraler Bestandteil der Unternehmensstrategie geworden [Pic03]. All dies macht die Forderung nach der Entwicklung von effizienten, zeitsparenden und kostengünstigen Entwicklungsprozessen verständlich. Zur Bewältigung der Komplexität von IT- Lösungen wurde von der Object Management Group die Model Driven Architecture vorgestellt. Ausgehend von diesem Vorschlag wurde von der MID GmbH ein modellbasierter Softwareentwicklungsansatz entwickelt. Im Mittelpunkt dieses Ansatzes stehen Modelle, die Softwaresysteme auf unterschiedlichen Ebenen beschreiben. Bei der Modellierung wird zwischen fachlichen und technischen Anforderungen eines Systems unterschieden. Zuerst werden die fachlichen Anforderungen ohne Rücksicht auf die technischen Anforderungen modelliert. Erst am Ende dieser Modellierung werden dann die technischen Anforderungen berücksichtigt, die nicht selten einer häufigen Veränderung unterliegen. Durch dieses Split bleiben die ersten Modellierungsstufen technisch immun und können so viel eher wieder verwendet werden. Um die Probleme der Wiederverwendung und Erweiterung von bestehenden Systemen zu bewältigen, wurde die serviceorientierte Architektur entwickelt. Damit werden die fachlichen Anforderungen in Form von Services modelliert. Um die Übersicht über eine große Zahl von Services zu behalten, werden sie nach bestimmten Kriterien zu Servicekomponenten zusammengefasst. Diese Servicekomponenten müssen dann ebenfalls die oben genannten Ziele der Wiederverwendung und Erweiterung erfüllen. Die Wiederverwendung von Servicekomponenten wird durch eine möglichst lose Kopplung gefördert, die Erweiterung ihrerseits durch eine hohe interne Kohäsion. Die lose Kopplung und die hohe interne Kohäsion bestimmen somit die Kriterien der Zusammensetzung der Service-Methoden zu Komponenten. 7

8 1. Einleitung 1.1 Aufgabenstellung und Zielsetzung Die Arbeit entsteht im Rahmen der Forschungen im Bereich der Architekturmodellierung des Lehrstuhls für Software Systems Engineering der TU Clausthal. Das Ziel dieses Forschungsprojektes ist die Entwicklung eines Verfahrens zur Identifikation von Komponentenstrukturen. Der Startpunkt des Verfahrens soll eine Liste von Service-Methoden sein. Je nach Ähnlichkeit bezüglich der Ein- und Ausgabetypen dieser Service-Methoden werden die Service-Methoden auf Komponenten abgebildet. Zur Optimierung der Komponentenstrukturen wird ein Metrikverfahren verwendet: Lack of Cohesion in Methods. Die Herausforderung besteht hier darin, ein effizientes Verfahren zur Analyse der Ähnlichkeit zwischen Service-Methoden zu entwickeln. Diese Arbeit fokussiert sich auf die Vorstellung und die Implementierung eines solchen Verfahrens. Es wird ein Prototyp des Verfahrens basierend auf das UML2-PlugIn entwickelt. Es wird für die Repräsentation der mit dem Verfahren erzeugten Komponentenstruktur in UML-Modellen das XMI-Format (XML Metadata Interchange) zum Einsatz kommen. Das Werkzeug selbst soll als Eclipse-PlugIn realisiert werden, das mit Hilfe des UML2-PlugIn auf die Modelle zugreift und diese bearbeitet. 1.2 Aufbau der Arbeit Die hier vorliegende Diplomarbeit gliedert sich neben der Einleitung in vier Kapitel, deren Inhalte im Folgenden kurz umrissen werden: Kapitel 2 gibt eine kurze Einführung in die für diese Arbeit relevanten Technologien. Einleitend wird auf die Model Driven Architecture sowie auf die Drei-Schichten-Architektur und die Serviceorientierte Architektur eingegangen. UML 2 basierend auf EMF wird ebenfalls kurz vorgestellt. Dabei handelt es sich um das Werkzeug zum Manipulieren von UML-Modellen, die als XMI-Datei im Repository vorliegen. Im Kapitel 3 wird eine Beispielanwendung vorgestellt. Sie wird mit Hilfe einer vorgegebenen Modellierungsmethodik basierend auf der Model Driven Architecture modelliert. Ziel der Modellierung ist die Ermittlung der angebotenen Services Service-Methoden der Anwendungsschicht. Zur Optimierung des Datenaustauschs werden Transferobjektklassen eingesetzt. Kapitel 4 wird der Beschreibung eines Verfahrens zur Identifikation von Komponenten gewidmet. Dieses Verfahren vergleicht die Ein- und Ausgabetypen der Service-Methoden und bildet daraus je nach Grad der Ähnlichkeit Cluster. Die so gebildeten Cluster werden dann auf Komponenten und deren Schnittstellen abgebildet. Das Optimierungsproblem besteht in diesem Fall darin, einerseits Komponenten zu bilden, die nach außen hin möglichst unabhängig sind (Stichwort: geringe Kopplung), andererseits nur solche Service-Methoden zu einer Komponente zusammen zu fassen, die möglichst viel miteinander zu tun haben (Stichwort: interne Kohäsion).Am Ende dieses Kapitel 8

9 1. Einleitung wird einen Verbesserungsvorschlag zur Optimierung des bisher bestehenden Verfahrens vorgestellt. Das Kapitel 5 befasst sich mit der Implementierung eines Prototyps des in Kapitel 4 vorgestellten Verfahrens zur Identifikation von Komponenten. Die Implementierung erfolgt in der Programmiersprache Java und verwendet das UML2-PlugIn, um auf die Service-Methoden zu zugreifen und die Komponenten zu erzeugen. 9

10 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung Die modellgetriebene Softwareentwicklung ist ein aktueller Trend in der Softwareentwicklung. Die Grundidee besteht darin, den Programmcode als ersten Schritt in der Softwareentwicklung durch Modelle abzulösen. So dienen Modelle als Ausgangspunkt für die Softwareentwicklung. Ausgehend vom Modell, das das Softwaresystem in seiner Gesamtheit beschreibt, werden werkzeugunterstützt weitere Modelle mit unterschiedlichen Sichten auf das Gesamtsystem abgebildet und letztendlich der Quellcode generiert. Solche Abbildungen werden als Transformationen bezeichnet. Sollen Änderungen in der Software auftreten, werden diese zuerst beim Modell durchgeführt und danach der Quellcode durch automatische Transformationen aus dem Modell erzeugt. In den folgenden Abschnitten werden die Motivationen, die zur Entwicklung von neuen Ansätzen geführt haben, betrachtet. Danach wird auf die von der Object Management Group (OMG) vorgeschlagene Lösung zur Bewältigung der Probleme der herkömmlichen Softwareentwicklungsprozesse eingegangen Probleme der heutigen Softwareentwicklungsprozesse Software gehört heute in einem solchen Ausmaß zu unserem Alltag, dass es undenkbar ist, sich von diesem Instrument zu trennen. Sei es in den Haushalten, in der Industrie, bei Banken, etc., alles oder fast alles funktioniert mit Hilfe von Software. In den meisten Unternehmen ist die Qualität der verwendeten Software sogar entscheidend für den Erfolg und die Wettbewerbsfähigkeit des Unternehmens. Software wird in immer mehr und wichtigeren Bereichen eingesetzt, darum steigen die Ansprüche und Anforderungen - wie z.b. Verfügbarkeit, Sicherheit, Zuverlässigkeit, etc. - an die Software. Aufgrund dieser immer steigenden Ansprüche und Anforderungen wächst die Komplexität von Software und macht diese kaum noch beherrschbar. Nach Untersuchungen der Standish Group in 2004 sind Softwareprojekte [Sta04]: Zu 29% erfolgreich Zu 53% gefährdet Zu 18% abgebrochen worden Diese Ergebnisse verdeutlichen die Forderung nach ingenieurmäßiger Softwareherstellung und den Einsatz von neuen, effizienteren und kostengünstigeren Entwicklungsprozessen, um die Effektivität der Softwareentwicklung zu steigern. Weitere Probleme, die die erfolgreiche Durchführung von Softwareentwicklung bzw. Softwaremodernisierung erheblich stören, sind nach [Gru06] unter anderen: 10

11 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung Dominierung von Fachlichkeit durch Technik: Softwareentwickler konzentrieren sich viel zu sehr auf die technischen Aspekte eines Projektes anstatt auf das notwendige Fachwissen zur Bewältigung des Projektes. Divergenz der Änderungszyklen Der Änderungszyklus des technischen Teils einer Software unterscheidet sich von dem des fachlichen Teils. Deswegen wäre es besser, diese beiden Teile bei der Entwicklung zu trennen. Gleichförmigkeit von Projekten Mit der Zeit werden Entwickler Projekte realisieren, die an manchen Stellen die gleiche Aufgabe lösen sollen, die bereits bei früheren Projekten gestellt worden sind, so dass die Architektur dieser Projekte an einigen Stellen sehr ähnlich ist. Aber anstatt an diesen Stellen die bereits entwickelte Architektur zu verwenden, wird sie wiederum komplett neu programmiert. Legacy Crisis Mit der zunehmenden Verkürzung der technologischen Änderungszyklen wächst auch der Druck zur Modernisierung bereits bestehender Anwendungen. Nach [Gru06] sind die Modernisierungskosten von 40% des Gesamtbudgets im Jahre 1970 heutzutage auf 90% angestiegen, so dass kaum noch Geld für neue Entwicklungen zur Verfügung steht. Die Ursache dieser explosiven Modernisierungskosten liegt darin, dass nach oder sogar bereits vor der Fertigstellung einer Anwendung neue Anforderungen an die Anwendung gestellt werden. Mit jeder Wartung der Anwendung versucht man, diese Anforderungen zu erfüllen. Aber gleichzeitig wächst die Komplexität der Anwendung mit jeder Wartung, bis sie sogar einen Punkt erreicht, ab dem sie kaum noch zu warten ist. Eine Modernisierung der Anwendung wird unumgänglich. Wartungs- und Modernisierungsphasen lösen sich gegenseitig so lange ab, bis die Anwendung eine Komplexität erreicht, die eine komplette Neuentwicklung der Anwendung erforderlich macht. Und dann beginnt der beschriebene Zyklus wieder von vorn. Eine von der OMG (Object Management Group) vorgeschlagene Lösung zur Bewältigung des oben beschriebenen Dilemmas der Softwareentwicklung ist die Model Driven Architecture (MDA) Model Driven Architecture Die MDA ist eine Ausprägung der modellgetriebenen Softwareentwicklung. Sie wurde 2002 von der Object Management Group (OMG) verabschiedet. Sie stützt sich bei der Spezifikation von Modellen auf eine Reihe weiterer, eigener OMG-Standards, z.b. Unified Modeling Language (UML) oder Queries Views Transformation (QVT) zur Beschreibung von Transformationsregeln [Dra06]. Konzeptionell unterscheidet die MDA verschiedene Ebene der Modellierung mit jeweils unterschiedlichem Abstraktionsgrad. Sie beginnt bei einer sehr abstrakten hard- und softwareunabhängigen Sichtweise und führt dann die entstehenden Modelle durch Transformationen auf 11

12 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung neue Modelle mit geringerem Abstraktionsgrad über, bis im finalen Schritt der Quellcode erzeugt wird. Die wesentlichen Ebenen der MDA-Modellierung sind: die plattformunabhängige und die plattformspezifische. Auf der plattformunabhängigen Ebene wird ohne Rücksicht auf die Zielplattform der Anwendung die Geschäftlogik modelliert. Auf der nächsten Ebene werden je nach Zielplattform die passenden Transformationsregeln verwendet, um das Modell zu verfeinern. Diese Trennung der Spezifikation eines Systems von den technischen Details hat nach [Kle03] folgende Vorteile: Portabilität: Ein plattformunabhängiges Modell kann dazu verwendet werden, viele unterschiedliche plattformspezifische Modelle zu erzeugen. Damit werden die Kosten und die Komplexität der Softwareentwicklung gesenkt und vor allem die Wiederverwendung des bereits existierenden Modells gesteigert. Höhere Produktivität: Alle an der Entwicklung der Software beteiligten Rollen können ihre eigenen gewohnten Sprachen und Konzepte verwenden. Die Produktivität in den einzelnen Teams wird dadurch gesteigert und dennoch die Integration in den Gesamtprozess nicht gestört. Verbesserte Dokumentation: Die MDA strebt einen möglichst hohen Informationsgrad des plattformunabhängigen Modells an, da die Spezifikation der Details auf Modellebene einfacher von statten geht als auf Quellcodeebene. Die Technologie der Model Driven Architecture ist in drei Basis-Ebenen gegliedert. Die Beschreibung dieser Ebenen ist das Ziel des nächsten Abschnittes. Aber zuvor werden einige wichtige Konzepte aus der Welt der MDA vorgestellt Vorgaben der Objekt Management Group Die OMG beschreibt in ihren Dokumenten Model Driven Architecture - A Technical Perspective [OMG01] und MDA Guide [OMG03] die Basiskonzepte, die eine zentrale Rolle innerhalb der MDA spielen. Im Folgenden werden einige diese Basiskonzepte vorgestellt. System Ein System ist ein aus Teilen zusammengesetztes und strukturiertes Ganzes. Es hat eine Funktion, erfüllt einen Zweck und verfügt über eine Architektur. Architektur In der Architektur findet sich die Organisation der Teile eines Systems, deren Verhalten sowie die Beziehung unter den einzelnen Komponenten wieder. Beziehungen können zudem an Bedingungen geknüpft sein, die zur Erreichung des Systemzwecks erfüllt werden müssen. 12

13 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung Modell Ein Modell ist eine Abstraktion von einer in der Realität existierenden Entität. Modelle werden verwendet, um Systeme zu einem bestimmten Zweck zu beschreiben. Dabei werden uninteressante Details des Systems verschwiegen und nur wichtige Aspekte dargestellt. Je mehr Einzelheiten, die für den gewünschten Überblick nicht von Bedeutung sind, in der Darstellung weggelassen bzw. vereinfacht werden, desto übersichtlicher wird das Modell. Metamodell Ein Metamodell ist eine Menge von Elementen mit denen Modelle, die sich auf dieses Metamodell beziehen, erstellt werden können. Es enthält die Regeln, die bei der Erstellung des Modells beachtet werden müssen (Syntax) sowie die Bedeutung der Elemente (Semantik). Plattform Eine Plattform ist eine Ausführungsumgebung für eine Anwendung. Typische Beispiele für Plattformen sind im Bereich der Betriebssysteme (Unix, Windows), der Programmiersprachen (C++, Java, C#) und der Middleware (CORBA, Java EE,.NET) zu finden Entwicklungsprozess der MDA Die OMG spezifiziert in drei verschiedene Abstraktionsebenen, die zuerst dazu dienen, die Applikation zu modellieren. Danach wird nach mehreren Transformationsschritten der Quellcode der Applikation generiert. Die Grenze zwischen den einzelnen Abstraktionsebenen ist noch nicht explizit und nicht standardisiert. Im Folgenden werden die einzelnen Ebenen beschrieben. CIM: Computational Independent Model (auch Geschäftsmodell genannt) beschreibt u.a. Geschäftsprozesse, involvierte Personen, Abteilungen, Beziehungen zwischen Prozessen und spezifiziert die Anforderungen an die zu realisierende Anwendung, ohne auf die technischen Details der Zielplattform einzugehen. Zu der Modellierung von CIM wird eine von Fach- und Entwicklungsexperten verständliche Modellierungssprache verwendet. Ziel ist es, die Kommunikationslücke zwischen diesen beiden Expertengruppen zu schließen. Üblicherweise wird als Modellierungssprache UML verwendet. PIM: Das Platform Independent Model beschreibt das System konzeptionell, das heißt, es beschreibt die Funktionalitäten eines Systems so, wie sie in der Realität existieren oder als sinnvoll erachtet werden. Wie diese Funktionalitäten in einer konkreten Plattform umgesetzt werden, ist für den Entwickler auf dieser Abstraktionsebene nicht weiter relevant. Da keine plattformspezifischen Details im PIM vorkommen, kann dieses auf verschiedenen Plattformen realisiert werden und ist somit resistent gegen Technologieveränderungen. PSM: Das Platform Specific Model ist speziell an eine konkrete Implementierungstechnologie gebunden. Es dient als Basis für die Generierung des Codes für die Zielplattform(en). Es existieren mehrere PSM-Ebenen. Die erste wird aus der Transformation des PIM erstellt. Die anderen PSMs 13

14 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung werden aus den aufeinander folgenden Transformationen bis zum Code in der Zielsprache (Java, C++, C#, etc.) generiert. Abb. 2.1: Lebenszyklus der MDA [Mar08] Der Übergang zwischen den verschiedenen Modellen wird durch eine Folge von Transformationen erledigt, wie aus Abb. 2.1 ersichtlich wird. Die OMG will langfristig diesen Übergang mit Hilfe von Software-Tools automatisieren. Es wird dann möglich sein, vom Analysemodell bis zum Einsatz der Lösung eine vollständige Generierung des Codes zu bewirken. Aber vorerst erfolgt dieser Übergang von Modell zu Modell halbautomatisch Modelltransformationen Eines der wichtigsten Merkmale von MDA ist die Transformation eines Modells in ein anderes. Die MDA-Spezifikation der Meta Object Facility (MOF) [OMG04] identifiziert folgende Transformationsarten, die während des Entwicklungszyklus einer Anwendung durchgeführt werden können: PIM zu PIM Transformation Diese Art der Transformation wird dann genutzt, wenn Modelle in der Anfangsphase der Entwicklung bereichert, gefiltert oder spezialisiert werden müssen ohne Zusatz von Plattforminformationen. Ein Beispiel dafür, dass eine PIM zu PIM Transformation angewendet werden kann, ist der Übergang von der Analyse- in die Design-Phase. Der Übergang von PIM zu PIM ist eine Verfeinerung des Modells. Dabei werden Zusatzinformationen in das Modell eingefügt. PIM zu PSM Transformation Erst wenn ein PIM so fortgeschritten ist, dass es mit plattformspezifischen Informationen angereichert werden kann, kann es in ein PSM umgewandelt werden. Die Spezifikationen 14

15 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung für eine solche Transformation ist in UML-Profilen enthalten. Die meist verwendeten Plattformen sind z.b. J2EE,.NET, CORBA. PSM zu PSM Transformation Diese Transformation bezieht sich auf ein plattformspezifisches Modell und gibt ein Modell dergleichen Plattform zurück. Sie wird verwendet, wenn es um die konkrete Realisierung von Komponenten und das Deployment geht. Die Codegenerierung, Kompilierung, Initialisierung und die Konfiguration sind Teile dieser Transformationsart. PSM zu PIM Transformation Mit dieser Transformation lässt sich eine konkrete Implementierung oder ein plattformspezifisches Modell in ein plattformunabhängiges Modell zurückführen. Diese Transformation - auch Reverse Engineering genannt - ist sehr komplex und kaum automatisierbar. Sie erfordert manuelle intellektuelle Arbeit, da nicht vorhandene Metainformationen rekonstruiert werden müssen. Abb. 2.2: Transformationsvarianten Abb. 2.2 fasst die verschiedenen möglichen Modelltransformationen zusammen. Ausgehend vom PIM durchläuft das Modell die verschiedenen Transformationen bis zur Erlangung des Codes. Die Abbildung zeigt, dass es auch möglich ist, aus einem Code ein PSM und dann ein PIM zu erhalten. Allerdings ist dies nur dann möglich, wenn der MDA-Ansatz eingehalten wurde. Wenn nicht, dann muss das traditionelle Reverse Engineering angewandt werden Meta Object Facility Die Meta Object Facility (MOF) der OMG ist eine modellbasierte Sprache zur Definition von Metamodellen. Die Instanzen von MOF wie z.b. UML werden als Modellierungssprachen eingesetzt. Die MOF und UML sind das Herz der MDA-Technologie, da diese beiden Standards die Erstellung von plattformunabhängigen Modellen ermöglichen. Die MOF ermöglicht auch den Austausch von Metadaten über die Systemgrenzen einer Anwendung hinaus. 15

16 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung Die MOF definiert vier Ebenen (von M0 bis M3) der Metamodellierung, wobei MOF selbst die dritte Ebene darstellt. Im Folgenden werden diese Modellierungsebenen genauer beschrieben. M0 Ebene M0 entspricht den Daten der realen Welt im laufenden System. Sie ist die unterste Ebene der Architektur und die hier enthaltenen Objekte sind Instanzen der Elemente aus M1. M1 Ebene Auf der M1 Ebene befindet sich das Modell zur Beschreibung der Daten aus M0. Die UML- Modelle, PIMs und PSMs gehören zu dieser Ebene. Die Modelle von M1 sind Instanzen der Metamodelle aus M2. M2 Ebene Diese Ebene ist die Metamodell-Ebene. Sie legt die Sprache für die Modellierung und die Grammatik der Darstellung der Modelle aus M1 fest. Das UML-Metamodell, das in UML Standard beschrieben ist und das die interne Struktur des UML-Modells definiert, gehört auch zu dieser Ebene. Die UML-Profiles, die die Möglichkeit bieten, das UML-Metamodell zu erweitern, sind auch hier angesiedelt. Die Metamodelle sind Instanzen des MOF. M3 Ebene Die M3 Ebene, das so genannte Metametamodell, ist die höchste Ebene des Modells. Die Metametamodell-Ebene beinhaltet das MOF. Das MOF beschreibt die Metamodelle M2. Das MOF ist eine selbstbeschreibende Sprache und hat keine Metaebene. Es ist somit eine Instanz von sich selbst. Innerhalb der OMG ist MOF die Standard M3-Sprache. Alle anderen Modellierungssprachen (wie UML, CWM, etc.) sind Instanzen von MOF. Die folgende Abbildung zeigt beispielhaft die vier Modellierungsebenen: Level Name Beispiel M3 Meta-Metamodell MOF-Metamodelle M2 Metamodelle UML-Metamodelle M1 Modelle UML-Klasse M0 Instanz/Daten Objekt Abb. 2.3: MOF-Ebene der Metamodellierung Der verwendete Entwicklungsprozess Dieser Entwicklungsrozess ist ein Softwareentwicklungsansatz basierend auf einer modellgetriebenen Architektur. Der fügt an die drei Modellierungsebenen der MDA eine weitere hinzu. Die Modellierungsebenen des verwendeten Entwicklungsprozess sind (siehe Abb. 2.4): Geschäftsprozessmodell, 16

17 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung Analysemodell, Entwurfsmodell, Realisierung. Abb. 2.4: Modellbasierter Entwicklungsansatz im Überblick [Rau07] Auf den einzelnen Modellierungsebenen werden folgende Aufgaben durchgeführt (vgl. [Rau07]): Die erste Modellierungsebene, das Geschäftsprozessmodell, entspricht dem CIM der MDA. Es enthält eine detaillierte Beschreibung der Geschäftsprozesse und der Geschäftswelt, bestehend aus Rollen, materiellen und immateriellen Gegenständen, IT- System- sowie IT-Anwendungslandschaft. Die zweite Modellierungsebene entspricht dem PIM der MDA. Dieses Modell beschreibt das Informationssystem konzeptuell und wird aus dem Geschäftsprozessmodell abgeleitet. Es besteht aus Systemanwendungsfällen und den Domänenentitäten. Danach folgt das Entwurfsmodell. Dieses Modell ist charakteristisch für M3 und hat keine Entsprechung in MDA. Es ist für den Entwurf der Dienst- und Komponenten-Struktur der einzelnen Schichten des Systems zuständig. Diese Ebene ist plattformunabhängig, aber bereits auf die Zielarchitektur zugeschnitten. Die letzte Ebene ist die Realisierung. Dabei entsteht ein Implementierungsmodell ähnlich wie bei dem PSM. Dieses Modell enthält eine technologiespezifische Beschreibung des Informationssystems. 17

18 2. Grundlagen 2.1 Modellgetriebene Softwareentwicklung Die in dieser Modellierungsmethodik verwendeten UML-Diagrammarten werden im nächsten Abschnitt ausführlich beschrieben. 2.2 UML UML ist eine von der OMG standardisierte Modellierungssprache für Software und andere Systeme. Sie definiert sowohl Notationselemente als auch Erweiterungsmechanismen, um eigene Diagrammtypen bzw. Modifikationen von Diagrammen auf Basis dieser Standardkonstrukte erstellen zu können. Weiterhin können auch völlig neue Modellierungssprachen ohne Vorlage erstellt werden. UML ist weder Methode noch Prozessmodell, insofern dass nicht festgelegt ist, wann und wo welcher Diagrammtyp verwendet wird. Hier ist Erfahrung gefragt. UML ist zu einer Standardsprache bei der Modellierung von Softwaresystemen geworden. In diesem Abschnitt werden einige der meist verwendeten Diagrammtypen bei der Entwicklung mit dem MDA-Prozess betrachtet. Danach wird das UML2-PlugIn vorgestellt Diagrammtypen In UML werden dreizehn Diagrammtypen unterschieden. Diese Diagrammtypen werden je nach Entwicklungsphase und Bedürfnissen der Entwickler verwendet. In dieser Arbeit werden nur die für uns relevanten Typen vorgestellt. Diese sind das Klassendiagramm, das Anwendungsfalldiagramm, das Paketdiagramm, das Komponentendiagramm und das Aktivitätsdiagramm Klassendiagramm Das Klassendiagramm gehört in UML zu den statischen Strukturdiagrammen. Es ist die wichtigste Komponente objektorientierter Softwareentwicklung. In diesem Diagramm werden die Klassen und ihre Beziehungen zueinander dargestellt. In einer Klasse wird das Verhalten eines Objekts beschrieben, indem Operationen zwar benannt, aber keine Details über das dynamische Verhalten gegeben werden. 18

19 2. Grundlagen 2.2 UML Abb. 2.5 stellt ein stark vereinfachtes Klassendiagramm einer Bibliothek dar. Abb. 2.5: Klassendiagramm Bibliothek Die Klasse wie z.b. Buch ist das wichtigste Element des Klassendiagramms. Die Klassen im Diagramm werden durch Linien miteinander verbunden; diese stellen somit die Beziehung dar, die zwischen den Klassen besteht. Es werden vier Beziehungsarten unterschieden: Assoziation, Aggregation, Komposition und Vererbung. Die Assoziation ist die allgemeine und meist verwendete Beziehung zwischen zwei Klassen (z.b. zwischen Ausleihgegenstand und Student ). Eine besondere Form der Assoziation ist die Aggregation. Die Aggregation stellt eine gewisse Teile-Ganz-Beziehung dar. Wenn bei der Zerstörung des Ganzen die Teile weiter existieren können, liegt eine Aggregation vor. Diese Beziehung wird durch eine leere Raute auf der Seite des Ganzen dargestellt. Ein Beispiel für eine solche ist die Beziehung zwischen Bibliothek und Ausleihgegenstand. Die Komposition ist eine starke Form der Aggregation. Bei der Komposition besteht zwischen Teil und Ganzem eine so genannte Existenzabhängigkeit. Die Teile hören mit dem Ende der Existenz des Ganzen ebenfalls auf zu existieren wie bei Buch und Kapitel. Die Vererbung stellt eine Verallgemeinerung der Eigenschaften von Klassen dar. Sie wird je nach Leserichtung Generalisierung oder Spezialisierung genannt. Z.B. sind Bücher und Zeitschriften Ausleihgegenstände. Ausleihgegenstände generalisieren die Klassen Buch und Zeitschrift, und Buch oder Zeitschrift ist eine Spezialisierung der Klasse Ausleihgegenstand. Die Assoziationen können mit Navigationspfeile versehen werden. Ist kein Navigationspfeil angegeben, dann kann die Assoziation in beide Richtungen navigierbar sein, sonst nur in Richtung der Navigationspfeile. 19

20 2. Grundlagen 2.2 UML Klassen werden in UML wie folgt dargestellt: Abb. 2.6: Darstellung einer Klasse in UML Eine Klassendarstellung enthält einen Klassennamen und Attribute, die die Daten und Zustände beschreiben, die eine konkrete Instanz einer Klasse annehmen kann. Was mit diesen Daten und Zuständen machbar ist, legen die Operationen fest Paketdiagramm Paketdiagramme werden benutzt, um Elemente zu gruppieren, zu einem gemeinsamen Namensraum zu vereinen und in einer Baumstruktur abzubilden. Ein Paket wird durch ein Rechteck dargestellt, das den Bezeichner auf der Lasche oben trägt. Innerhalb des Rechtecks werden die zugehörigen Elemente eingetragen. Die Elemente des Pakets können Klassen oder weitere Pakete sein. Eine Klasse eines Pakets ist für alle anderen Klassen desselben Pakets erreichbar. Um zu bestimmen, ob eine Klasse eines Pakets von Klassen eines anderen Pakets z.b. durch eine Import- Beziehung erreichbar wird, kann jedem Element eine Sichtbarkeit zugeordnet werden. Im Falle von - (private) ist eine Klasse nur in seinem Paket erreichbar und bei + (public) ist eine Klasse von jeder anderen Klasse in jedem anderen Paket erreichbar. Pakete können Elemente anderer Pakete importieren (engl. import), benutzen (engl. access) oder ihre Elemente mit denen des anderen Pakets verschmelzen (engl. merge). Die graphische Darstellung dieser Sachverhalte ist in Abb. 2.7 zu finden: Abb. 2.7: Beziehungen zwischen Paketen 20

21 2. Grundlagen 2.2 UML import: Elemente aus importierten Paketen können unqualifiziert innerhalb des importierenden Pakets verwendet werden. Zudem ist der Zugriff von außen auf die importierten Elemente durch eine Referenzierung über das importierende Paket möglich. access: wie import, aber der Unterschied ist, dass die importierten Elemente innerhalb des importierenden Pakets die Sichtbarkeit private besitzen, also nicht an andere Elemente außerhalb des Pakets weitergegeben werden können. merge: Durch die Anwendung dieser Assoziation entstehen im Quellpaket neue Elemente, die aus den ursprünglich im Quellpaket vorhandenen Elemente bestehen, die von den Elementen gleichen Namens des Zielpakets (das Paket auf das der Pfeil zeigt) erben Komponentendiagramm Komponenten sind wieder verwendbare Software-Einheiten, mit denen Systeme konstruiert werden können. Eine Komponente hat wohldefinierte Schnittstellen. Gut entworfene Komponenten hängen nicht direkt von anderen Komponenten ab, allenfalls von Schnittstellen anderer Komponenten. Nur dann kann eine Komponente durch eine andere Komponente, die dieselbe Schnittstelle unterstützt, ersetzt werden. Eine Komponente hat Schnittstellen, die sie unterstützt, und Schnittstellen, die sie verwendet. Komponenten werden entweder durch Verwendung des Stereotypen <<component>> oder durch Verwendung des Komponentensymbols in der rechten oberen Ecke des Rechtecks gekennzeichnet. Die inneren Elemente einer Komponente realisieren, alleine oder in Zusammenarbeit mit anderen Komponenten, die Services, die die Komponente über ihre Schnittstellen anbietet. Abb. 2.8: Notation Komponentendiagramm (vgl. [Gru06]) Komponenten können weitere Komponenten enthalten. Diese inneren Komponenten können über Ports ihre Schnittstellen nach außen anbieten, ebenso kann die äußere Komponente Aufgaben an innere Komponenten delegieren. In Abb. 2.8 wird dies zwischen Komponente A und Komponente D realisiert. Delegationen werden durch eine gerichtete Assoziation mit Stereotyp <<delegate>> dargestellt. 21

22 2. Grundlagen 2.2 UML Die Artefakte stellen im Allgemeinen alle Arten von physischen Einheiten zur Laufzeit des Systems wie Files, ausführbare Dateien, Modelle etc. dar. Sie repräsentieren binäre Instanzen einer Komponente zur Laufzeit und stehen damit zu ihnen in etwa in der Beziehung, wie Objekte zu Klassen. Die Beziehung zwischen Artefakten und Komponenten wird durch die Abhängigkeitsbeziehung mit Stereotyp <<manifest>> dargestellt. Es kann zwischen Artefakten die Verwendungsbeziehung bestehen dargestellt durch den Stereotyp <<use>>. Abhängigkeiten werden durch gestrichelte Pfeile dargestellt, und sie haben dieselbe semantische Bedeutung wie beim Klassendiagramm. Abhängigkeiten legen lediglich fest, dass das Modellelement, von dem der Abhängigkeitspfeil ausgeht, das referenzierte Element zurr Erfüllung seiner Aufgaben benötigt. Wenn die Abhängigkeiten zwischen Komponenten durch Schnittstellen vermittelt werden, können die Komponenten leicht ausgetauscht werden. Der Unterschied zwischen Komponentendiagrammen und Paketdiagrammen besteht darin, dass die Paketdiagramme ein allgemeines Mittel für die Strukturierung darstellen, während die Komponentendiagramme Implementierungsaspekte zeigen. In der Praxis entspricht eine Komponente einem Paket, aber nicht jedes Paket ist eine Komponente Technologie An dieser Stelle werden zwei Schlüsseltechnologien, die zur Realisierung der oben eingeführten Verfahren eine wesentliche Rolle spielen, vorgestellt. Diese Technologien werden im Laufe dieser Arbeit verwendet, um Modelle aus der Beispielanwendung zu bearbeiten. Da diese Technologien in der Entwicklungsumgebung Eclipse laufen, wird an diese Stelle eine kurze Einführung in den grundsätzlichen Aufbau von Eclipse gegeben. Eclipse wurde ursprünglich von IBM konzipiert und danach an ein Open Source Konsortium für die Weiterentwicklung übergeben. Die erste Version von Eclipse Version 1.0 erschien im November Charakteristisch für Eclipse ist sein modularer Aufbau, der in Abb. 2.9 dargestellt ist. 22

23 2. Grundlagen 2.2 UML Abb. 2.9: Modularer Aufbau des Eclipse [Gru06] Abb. 2.9 zeigt schematisch den modularen Aufbau von Eclipse. Das Runtime Kernel (graues Kästchen) ist der Kern von Eclipse. Sie wird auch Eclipse platform genannt. Die übrigen Kästchen (in weiß) stellen die konkreten Anwendungen der Plattform dar (wie z.b. Java Entwicklungsumgebung, Debugger, CVS Client, etc.) und sind Erweiterung des Kerns. Diese Erweiterungen sind an Erweiterungspunkten (engl. Extension Points) mit dem Kern verbunden und sie dienen wiederum selbst als Grundlagen für weitere Komponenten. Diese Komponenten oder Erweiterungen werden als PlugIn bezeichnet. Neben Eclipse spielen die folgenden PlugIns eine wichtige Rolle für diese Arbeit, wenn es darum geht, mit Modellen zu arbeiten Eclipse Modeling Framework (EMF) EMF ist ein Java-Framework zum Erstellen von Werkzeugen und anderen Anwendungen auf der Grundlage von strukturierten Modellen. EMF wurde als PlugIn konzipiert und neben seiner Integration in Eclipse kann dieses auch in Standalone-Anwendungen genutzt werden. EMF ist für diese Arbeit wegen den folgenden Aufgaben interessant: Laden und Speichern von Modellen (Deserialisieren/Serialisieren) Aufbau von Modellen Manipulation von Modellen EMF ermöglicht es, ausgehend von einem Metamodell Modelle zu erstellen und zugehörige Java- Implementationen zu generieren. Die abstrakte Syntax des verwendeten Metamodells selbst wird durch das EMF-Modell Ecore [Gru06] beschrieben. Ecore ist demnach das der EMF zugrunde liegende Metametamodell und unterscheidet sich von MOF dadurch, dass nur die Konstrukte zur Definition von MOF-Modellen aufgefasst werden. Die Beschreibung des Ecore-Modells selbst kann wiederum mit dem Ecore-Modell vorgenommen werden. Ecore ist demnach selbstbeschreibend und lässt sich genau wie das MOF-Modell in die Ebene M3 der in Abb. 2.3 erwähnten Modellierungshierarchie einordnen. Zum Austausch von EMF-konformen Modellen auf EMF-basierende Anwendungen wird das XMI benutzt (siehe ). 23

24 2. Grundlagen 2.2 UML Im Folgenden wird ein weiteres PlugIn vorgestellt. Es ist das wichtigste Werkzeug dieser Arbeit und wird dazu dienen, einen Prototyp des in Kapitel 4 vorzustellenden Verfahrens zu entwickeln UML2-PlugIn Das UML2-PlugIn ist eine EMF-basierte Implementierung des UML 2.x-Metamodells. Es wird vor allem zur Erledigung der folgenden Anforderungen an UML2-Modelle verwendet: Laden und Speichern von Modellen (Deserialisierung/Serialisierung) Aufbau des Modell-Repository Manipulation von Modellelementen innerhalb des Repositorys Die UML2-API bietet Methoden an, die auf diesem Repository arbeiten und das Modell programmatisch verändern können. Mithilfe der UML2-API können Tools für die graphische Modellierung entwickelt werden. Die programmatische Veränderung von UML2-Modellen, die durch UML2-API ermöglicht wird, ist der Grund, weshalb diese in dieser Arbeit überhaupt benutzt werden. Denn es geht darum, Modelle, die im Speicher als XMI-Dateien (siehe unten) vorliegen, zu laden, ein Objektnetz, das dem UML-Modell entspricht, zu bauen, Manipulationen auf diesen vorzunehmen (z.b. Klassenname ändern) und am Ende die veränderte oder neu erzeugte Datei wieder zu speichern. Um UML-Modelle (de)serialiesieren zu können greift das UML2-API auf das Ecore-Modell von EMF. Da EMF mit unterschiedlichen Modellen z.b. XML-Schema arbeiten kann, ist es wichtig, zu spezifizieren, welches Resource Implementierung von EMF benutzt wird für die (de)serialisierung der Daten. Da es in Rahmen dieser Diplomarbeit mit XMI-Dateien gearbeitet wird, wird die Klasse org.eclipse.emf.ecore.xmi.impl.xmiresourcefactoryimpl benutzt XML Metadata Interchange XML Metadata Interchange (XMI) ist ein Standard für die Serialisierung beliebiger MOF-basierter Metamodelle und legt die Regeln zur Erstellung von XML-Schemata aus diesen fest. Durch die Serialisierung (jede Modell-Klasse wird durch ein XML-Element mit deren Namen repräsentiert, in dessen Deklaration dann die Properties (Eigenschaften) dieser Klasse auftauchen) wird der Austausch von Modellen zwischen Plattformen, die die MOF Standards unterstützen, realisiert. 2.3 Zielarchitektur In diesem Kapitel wurde die MDA als effizienter, zielgerichteter, flexibler Softwareentwicklungsansatz vorgestellt. Danach wurde die M3 als eine leicht modifizierte MDA mit vier statt drei Abstraktionsebenen dargestellt. Die neu eingefügte Abstraktionsebene war das Entwurfsmodell (oder auch Architecture Specific Model (ASM)). Diese Abstraktionsebene ist die Ebene dieser 24

25 2. Grundlagen 2.3 Zielarchitektur Arbeit. Das entwickelte Verfahren zur Optimierung des Entwicklungsprozesses wird auf dieser Ebene durchgeführt. Der Entwicklungsprozess soll folgende Bedingungen einhalten: Das zu entwickelnde System soll in eine Drei-Schichtenarchitektur unterteilt werden. Diese besteht aus einer Präsentationsschicht, einer Anwendungsschicht und einer Datenhaltungsschicht. Die Anwendungsschicht soll Services an die beiden anderen Schichten anbieten. Diese Services sollen zu Komponenten zusammengefasst werden. In den nächsten Abschnitten werden diese Anforderungen beschrieben Schichtenarchitektur Eine Schichten-Architektur ist die Strukturierung eines Systems in Schichten aus Komponenten, die auf der gleichen Abstraktionsebene angesiedelt sind. Komponenten einer höheren Schicht können zur Erledigung ihrer Aufgabe auf Komponenten der gleichen und der unmittelbar darunter liegenden Schicht zurückgreifen [Wun05]. Die Aspekte der fachlichen und technischen Architektur werden in drei Schichten nämlich Präsentationsschicht, Anwendungsschicht, Datenhaltungsschicht zugeordnet. Die Unterstützungsschicht bietet querschnittliche Funktionalitäten. Abb stellt die Schichten-Architektur dar. Abb. 2.10: Schichten-Architektur Im Folgenden werden die einzelnen Schichten beschrieben: 25

26 2. Grundlagen 2.3 Zielarchitektur Präsentationsschicht: In dieser Schicht werden alle Funktionen zusammengefasst, die für die Anzeige und die Eingabe von Daten durch Benutzer der unterschiedlichen Applikationen nötig sind. Diese Schicht kann in HTML für Web-Applikationen oder im WML für Handy oder auch je nach Einsatzbereich in anderen Programmiersprachen implementiert werden. Anwendungsschicht: In der Anwendungsschicht befinden sich Komponenten, die die Geschäftlogik des Systems kapseln. Diese Komponenten sind über ihre Schnittstelle ansprechbar und führen die Berechnung und Manipulation der Daten durch. Die Anwendungsschicht versteckt die Datenhaltungsschicht vor der Präsentationsschicht. Sie empfängt Anforderungen aus der Präsentationsschicht, verarbeitet diese und greift - wenn nötig - auf Komponenten aus der Datenhaltungsschicht zu. Datenhaltungsschicht: Die Datenhaltungsschicht ist zuständig für die Verwaltung der Daten, mit denen die Applikation arbeitet. Eine wichtige Eigenschaft dieser Schicht ist, dass die Daten persistent sind, d.h. selbst wenn die Applikation nicht ausgeführt wird, werden die Daten irgendwo abgelegt, bis sie das nächste Mal gebraucht werden. Die Datenhaltungsschicht kann einfach aus einem Dateisystem bestehen; aber in den meisten Fällen ist diese eine Datenbank. Neben der reinen Speicherung der Daten ist die Datenhaltungsschicht verantwortlich für die Konsistenz der Daten, die sie enthält. Unterstützungsschicht: Diese Schicht bietet Funktionalitäten, die in allen restlichen Schichten relevant sind. Dazu gehören insbesondere: Fehlermanagement, Verwaltung von Konfigurationsinformationen, Authentifizierung/Autorisierung und Internationalisierung Komponenten Der Begriff der Komponente ist ein vielfach überladenes Begriffsfragment der EDV- und vor allen Dingen der objektorientierten Welt; dennoch gibt es bis jetzt keine einheitliche Begriffsdefinition. Für diese Arbeit sind folgende sich ergänzende Definitionen grundlegend. Eine der bekanntesten Definitionen wurde von Szyperski [Sky98] gegeben und lautet: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. 26

27 2. Grundlagen 2.3 Zielarchitektur In dieser Definition vermittelt Szyperski die Kerneigenschaften von Komponenten. Die grundlegendste ist, dass eine Komponente eine abgeschlossene Einheit bildet. Weiterhin verfügt eine Komponente über klar definierte Schnittstellen, über die sie ihre Dienste anbietet, und hat explizite Abhängigkeiten zu ihrem Umfeld. Komponenten können unabhängig entwickelt, verteilt und durch Dritte kombiniert werden. Die UML [Gro05] definiert ihrerseits eine Komponente wie folgt: A component is a modular, deployable and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. Nach der UML-Definition gibt es bei der Entwicklung von Komponenten eine klare Trennung von Schnittstelle und Implementierung. Die Implementierung sollte versteckt bleiben; der Zugriff auf die Komponente hingegen erfolgt über ihre Schnittstelle. An dieser Stelle wird die für diese Arbeit verwendete Definition des Begriffs Komponente vorgestellt: Eine Servicekomponente realisiert Services, welche in Interfaces durch Servicemethoden definiert sind, die zusammen eine sinnvolle Einheit ergeben und eine oder mehrere zusammengehörige Aufgaben durchführen. Diese kommuniziert mit ihrer Umgebung über klar definierte Schnittstellen. Nach dieser Definition wird eine Komponente aus einer Ansammlung von Methoden, die eine gewisse Ähnlichkeit die noch vorgestellt wird aufweisen, zusammengesetzt, und diese kommuniziert mit der Außenwelt ausschließlich über ihre Schnittstellen. Aus den vorausgegangenen Begriffsdefinitionen der Komponente lassen sich ihre Eigenschaften ableiten. Die folgende Aufstellung stützt sich im Wesentlichen auf [Bar08]. Kompositionsfähigkeit: Bei der komponentenorientierten Entwicklung entstehen Systeme aus Komponenten, die zusammensetzbar (kombinierbar) sind. Jede Komponente wiederum kann eine oder mehrere Komponenten besitzen. Das Komponentenmodell sollte Mittel und Regeln darüber, wie Komponenten kombiniert werden, zur Verfügung stellen. Dies ist nach [Bar08] die Kerneigenschaft von Software-Komponenten. Wiederverwendbarkeit: Einmal erstellte Komponenten können wieder verwendet werden, ohne dass sie modifiziert werden müssen. Dies ist ein wichtiger Vorzug von Komponenten. So kann eine Komponente in mehreren Kontexten verwendet werden, die der Komponentenentwickler nicht unbedingt alle vorhergesehen haben muss. 27

28 2. Grundlagen 2.3 Zielarchitektur Eindeutige Identifizierbarkeit: Eine Komponente sollte sowohl in ihrer Entwicklungsumgebung als auch in ihrer Laufzeitumgebung eindeutig identifizierbar sein, damit Verwechslungen ausgeschlossen sind. Modulares Design und Kapselung: Bei Komponenten, die aus mehreren Teilen bestehen, wird zwischen öffentlichen und privaten Teilen unterschieden. Die Implementierung bleibt versteckt. Lose Kopplung: Es sollte möglich sein, während der Laufzeit in einer Anwendung aus Komponenten eine Komponente durch eine andere zu ersetzen. Selbstbeschreibung: Die Dokumentation kann als Teil der Komponentenspezifikation betrachtet werden. Eine gute Dokumentation sollte sowohl die Komponente selbst beschreiben als auch ein Beispiel zu ihrer Verwendung zur Verfügung stellen [Bar08]. Einer der größten Risikofaktoren in bestehenden und neuen Software-Architekturen ist die Komplexität. Dort, wo fachliche Komplexität unvermeidbar und auch bei guter Dokumentation schnell undurchschaubar werden kann, schafft die Entwicklung von Software in Einzelteilen die Möglichkeit, die Komplexität der Applikation auf die Schwierigkeiten der Realisierung jeder einzelnen Komponente zu begrenzen Serviceorientierte Anwendungsschnittstelle Mit der Verbreitung von Webservices hat die serviceorientierte Anwendung (SOA) stark an Interesse gewonnen, obwohl sie seit langem bekannt war. Sinn und Zweck von SOA ist die Wiederverwendung bestehender Funktionalitäten und die damit verbundene Kostenreduktion in der Entwicklung neuer Dienste, die auf den bereits bestehenden Diensten und deren Funktionalitäten aufbauen. Ein SOA dient demnach dazu, schnell und einfach entfernte Funktionen zu nutzen oder solche anzubieten. Das Hauptziel von SOA ist dabei die Entkoppelung sämtlicher Softwareeinheiten. Die genutzten oder angebotenen Funktionen der SOA stellen die Services dar. Diese bilden somit den Hauptbestandteil der serviceorientierten Anwendungen. Ein Service definiert eine abgeschlossene Verantwortlichkeit an einer technologieneutralen Schnittstelle. Der Service sollte soweit möglich zunächst einmal unabhängig von einem anderen Service verwendbar und ausreichend dokumentiert sein [Wun05]. In [Wun05] wird SOA wie folgt definiert: Eine serviceorientierte Anwendung ist eine Ansammlung von Services, die miteinander kommunizieren, um eine bestimmte Aufgabe zu erledigen. 28

29 2. Grundlagen 2.3 Zielarchitektur Die serviceorientierte Anwendung lässt sich am einfachsten anhand der von ihr spezifizierten Rollen charakterisieren, die die jeweiligen Komponenten, die diese Anwendung implementieren, einnehmen. Die Hauptrolle spielt der Serviceanbieter (sog. Service Provider), der Services anhand von Schnittstellen zur Verfügung stellt, die er selbst implementiert und die von Servicenutzern (sog. Service Requester) in Anspruch genommen werden. Servicenutzer und Serviceanbieter sind untereinander lose gekoppelt, wodurch ebenfalls andere Servicenutzer diesen Service in Anspruch nehmen können. Die von einem Serviceanbieter zur Verfügung gestellten Services können in einer in computerverarbeitbarer Form spezifizierten Schnittstellenbeschreibung von Servicenutzern in Erfahrung gebracht werden. Darüber hinaus existiert neben Serviceanbieter und Servicenutzer ein Serviceverzeichnisdienst (sog. Service Repository), der die von Serviceanbietern veröffentlichten Schnittstellen verwaltet und anhand dessen Servicenutzer, die spezielle Services in Anspruch nehmen wollen, den jeweiligen Serviceanbieter, der beim Serviceverzeichnisdienst registriert ist, ermitteln können. Die SOA-Services setzen sich aus einer oder mehreren Methoden zusammen, den so genannten Servicemethoden. In einer Schichten-Architektur befinden sich diese Servicemethoden in der Anwendungsschicht. Die Daten, die von der Servicemethode als Ein- und Ausgabe verwendet werden, sind nur (semantische) Kopien der Daten, welche sich auf der Datenhaltungsschicht befinden. Eine solche Kopie wird als service data object (SDO) oder auch transfer object (TO) bezeichnet. Am Ende der Programmausführung findet über Data Access Service (DAS) ein Abgleich zwischen der Kopie des Servicenutzers und dem realen Wert in der Datenhaltungsschicht statt. Das nächste Kapitel dieser Arbeit befasst sich mit einer Beispielanwendung. Diese Anwendung wird alle in diesem Kapitel vorgestellten Technologien verwenden: die Schichten-Architektur, Komponenten und eine serviceorientierte Anwendungsschicht. Es handelt sich also um die Entwicklung eines Systems in einer Drei-Schichten-Architektur und mit einer serviceorientierten Anwendungsschicht. Dabei werden die Servicemethoden der Anwendungsschicht zu Komponenten zusammengefasst. Es stellt sich zudem die Frage, nach welchen Kriterien die Servicemethoden zu Komponenten zusammengefasst werden und wie die Schnittstellen der erstellten Komponenten aussehen. Die Bildung von Komponenten aus Service-Methoden ist keine triviale Aufgabe und stellt das Hauptziel dieser Arbeit dar. In Kapitel 4 wird ein Verfahren zur Bewältigung dieser Aufgabe vorgestellt, dessen Implementierung Gegenstand des Kapitels 5 ist. 29

30 3. Beispielanwendung: Bibliothek 3.1 Beschreibung der Beispielanwendung 3. Beispielanwendung: Bibliothek In diesem Kapitel wird eine Beispielanwendung vorgestellt. Sie wird dazu dienen, die in den folgenden Kapiteln vorzustellende Modellierungstechnik zu demonstrieren. Bei dieser Beispielanwendung handelt es sich um ein System zur Bibliotheksverwaltung. Um das eigentliche Ziel dieser Arbeit nicht aus den Augen zu verlieren, wird das Beispiel stark vereinfacht und einige Teile der Anwendung werden weggelassen. Für die Realisierung dieser Beispielanwendung wurde ein architekturspezifisches Modell, das in Abschnitt vorgestellt wurde, vorgegeben. Dieses Kapitel untergliedert sich in folgende Teile: Im ersten Teil wird die Beispielanwendung beschrieben. Im zweiten Teil wird auf die Modellierung des Beispiels eingegangen. Dabei wird besonders Wert auf das Analysemodell und das Entwurfsmodell gelegt. Denn das Hauptziel bei der Modellierung des Beispiels ist es, die Servicemethoden und die Transferobjektklassen zu ermitteln und danach die Servicemethoden zu wieder verwendbaren Komponenten zusammenzufassen. 3.1 Beschreibung der Beispielanwendung In dieser Arbeit verwenden wir eine durchgängige Beispielanwendung, anhand derer die Nutzung der oben vorgestellten Modellierungsmethodik erklärt wird. Diese Anwendung dient dazu, die Publikationen (Bücher und Magazine) einer Bibliothek zu verwalten. Zur Verwaltung der Bibliothek gehören das Einfügen, das Löschen und die Änderung des Publikationsbestands. Bücher können ausgeliehen und bis Ablauf der Ausleihfrist zurückgegeben werden, sonst wird eine Mahnung an den Benutzer erstellt. Falls bei einem Ausleihvorgang das gewünschte Buch nicht mehr zur Verfügung steht, kann dieses vorgemerkt werden. Steht das Buch wieder bereit, wird der Benutzer, der dieses vorgemerkt hat, benachrichtigt. Die Magazine sind Präsenzbestände der Bibliothek. Sie können nicht ausgeliehen werden; sie werden nur in der Bibliothek gelesen. Wenn eine Ausgabe eines Magazins fehlt, wird diese bestellt. Bevor die Benutzer die Leistung der Bibliothek im Anspruch nehmen können, müssen sie sich registrieren lassen. Bei der Registrierung geben sie ihre persönlichen Daten (Name, und Telefonnummer) und ihre Adresse (Strasse, Hausnummer, PLZ und Stadt) an. Da die angebotenen Funktionalitäten einer konkreten Bibliothek zu umfangreich wären, um sie hier zu beschreiben, beschränken wir uns auf die oben stehenden Anwendungsfälle. Sie decken aber alle Aspekte des in dieser Arbeit beschriebenen Modellierungsverfahrens ab. Im Folgenden wird das Datenmodell des Bibliotheksystems dargestellt. Es besteht aus den Klassen Publikation, Buch, Magazin, Autor, Verleger, Benutzer, Adresse, Mahnung, Ausleihen, Vormerken, Bestellen. 30

31 3. Beispielanwendung: Bibliothek 3.1 Beschreibung der Beispielanwendung Die Klassen Buch und Magazin sind Ausprägungen der Klasse Publikation. Jedes Buch hat einen oder mehrere Autoren und jeder Autor kann ein oder mehrere Bücher geschrieben haben. Deswegen besteht zwischen den Klassen Buch und Autor eine M:N-Beziehung. Ein Magazin wird von einem Verleger ausgegeben, und dieser kann mehrere Magazine ausgeben. Zwischen Magazin und Verleger besteht eine 1:N-Beziehung. Dies ist auch der Fall zwischen den Klassen Adresse und Benutzer und den Klassen Ausleihen und Mahnung. Bücher können von Benutzern ausgeliehen oder vorgemerkt werden. Da Benutzer mehrere Bücher ausleihen oder vormerken können und umgekehrt, besteht dann normalerweise zwischen Benutzer und Buch eine M:N-Beziehung. Um die Informationen über diese beiden Vorgänge zu speichern, werden sie zu eigenständigen Klassen (die Klasse Vormerken und die Klasse Ausleihen) implementiert und die alte M:N-Beziehung wird in 1:N-Beziehungen zwischen Benutzer und Ausleihen bzw. zwischen Benutzer und Vormerken und in N:1-Beziehungen zwischen Ausleihen und Buch bzw. zwischen Vormerken und Buch gesplittet. Diese Art der Beziehung besteht auch zwischen Benutzer und Magazin. Abb. 3.1: Datenmodell der Bibliothek Abb. 3.1 zeigt das Datenmodell der Beispielanwendung in Form eines UML-Klassendiagramms. Die Beziehung zwischen Klassen wird mit Hilfe von Assoziationslinien und Kardinalitäten dargestellt. Zwischen Buch, Magazin und Publikation besteht eine Vererbungsbeziehung. Die Klasse Buch erweitert die Klasse Publikation um das Attribut ISBN und die Klasse Magazin erweitert die Klasse Publikation um das Attribut ISSN. Die Assoziationsklasse Bestellen speichert mit Hilfe der Attribute Datum und Preis Informationen über die Bestellung. Vormerken und 31

32 3. Beispielanwendung: Bibliothek 3.1 Beschreibung der Beispielanwendung Ausleihen sind ebenfalls Assoziationsklassen, die mit ihren Attributen Informationen über diese Vorgänge speichern. Der nachfolgende Abschnitt befasst sich mit der Modellierung der Beispielanwendung. Ziel der Modellierung ist es, die Service-Methoden aus den Anwendungsfällen der Bibliothek und die Transferobjektklassen aus dem Datenmodell (siehe Abb. 3.1) abzuleiten. 3.2 Modellierung der Beispielanwendung Die oben vorgestellte Beispielanwendung wird nun modelliert. Für diese Modellierungsarbeit wird die in Abschnitt vorgestellte Modellierungsmethodik verwendet. Bei diesem Verfahren werden vier aufeinander folgende Modellierungsstufen durchlaufen: Geschäftsprozessmodell, Analysemodell, Entwurfsmodell, Realisierung. Am Ende der dritten Modellierungsstufe (Entwurfsmodell) erhält man eine Menge von Service- Methoden und eine Menge von Transferobjektklassen. Die Service-Methoden bilden die angeboten Dienste der Anwendungsschicht und die Transferobjektklassen die Ein- und Ausgabetypen der Service-Methoden. In der Realisierungsstufe werden die Service-Methoden zu Service- Komponenten der Anwendungsschicht zusammengefasst. Nach einer kurzen Einführung in das Geschäftsprozessmodell wird ausführlich auf das Analysemodell (Kap ) und auf das Entwurfsmodell (Kap ) eingegangen. Die Realisierung ist Teil des Kapitels 4. Bei dem Geschäftsprozessmodell werden die Geschäftsanwendungsfälle ermittelt und das Geschäftsanwendungsfalldiagramm erstellt. Mit Hilfe dieses Diagramms werden die Anwendungslandschaften (sog. Geschäftsfelder) und die darin enthaltenen Anwendungsfälle (sog. Geschäftsprozesse) dargestellt. Abb. 3.2 zeigt das Geschäftsanwendungsfalldiagramm der Beispielanwendung. 32

33 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung Abb. 3.2: Geschäftsanwendungsfalldiagramm Der erste Anwendungsfall Publikation anlegen fügt eine neue Publikation in das System ein. Dabei muss unterschieden werden, ob es sich um ein Buch oder um ein Magazin handelt. Das ist der Grund für die beiden Erweiterungen Buch anlegen und Magazin anlegen. Diese beiden Erweiterungen sind optional und sind deswegen zu Publikation anlegen mit einer extend- Beziehung verbunden. Der zweite Anwendungsfall Publikation bearbeiten ist noch komplexer. Vor der Bearbeitung einer Publikation, sei es ein Buch oder ein Magazin, muss sie zuerst z.b. über ihren Namen gesucht werden. Nachdem die Publikation gefunden wurde, kann sie bearbeitet werden. Das System bietet die Möglichkeit, die Daten einer Publikation zu aktualisieren und diese wieder zu speichern. Publikationen können auch vom System entfernt werden. So lässt sich der Anwendungsfall Publikation bearbeiten in drei Anwendungsfälle zerlegen: Publikation suchen, Publikation speichern und Publikation löschen. Der Anwendungsfall Publikation suchen wird bei jeder 33

34 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung Bearbeitung einer Publikation durchlaufen; dies wird mit der include-beziehung signalisiert. Die übrigen Anwendungsfälle sind optional. Die anderen Anwendungsfälle dieser Abbildung sind auch in dieser Weise gebildet. Sie werden in ihre einzelnen Bestandteile zerlegt und die Anwendungsfälle, die in jedem Fall durchlaufen werden, werden mit einer include-beziehung gekennzeichnet und die optionalen mit einer extend- Beziehung. Nun werden in der nächsten Phase der Modellierung die Anwendungsfälle weiter verfeinert, um die Service-Aktivitäten abzuleiten, die dann später in Service-Methoden abgebildet werden Analysemodell Der Ausgangspunkt des Geschäftsprozessmodells war das Geschäftsanwendungsfalldiagramm und die darin enthaltenen Geschäftsanwendungsfälle. Dieses Diagramm gab keine zufrieden stellende Antwort auf die Frage, welche Aktionen vom Benutzer und welche vom System durchgeführt werden. Das Ziel dieser Modellierungsstufe ist die Ermittlung von Service-Methoden, d.h. der Aktionen, die exklusiv vom System durchgeführt werden. Sie bilden dann die Dienste der Anwendungsschicht. Die Ermittlung der Transferobjektklassen hingegen ist Gegenstand des Entwurfsmodells. Um die Service-Methoden zu identifizieren, werden die Geschäftsanwendungsfälle verfeinert. Dies wird mit Hilfe von Aktivitätsdiagrammen durchgeführt, die wiederum in Bereiche unterteilt werden: ein Bereich für die Aktivitäten des Benutzers und ein Bereich für die Aktivitäten des Systems. Der Kontrollfluss der Aktivitäten wird mit Hilfe von Pfeilen dargestellt. Die Aktivitäten, die sowohl vom Benutzer als auch vom System durchgeführt werden, werden an der Grenze zwischen diesen beiden Bereichen dargestellt. Diese Aktivitäten werden in weiteren Schritten wieder durch Aktivitätsdiagramme verfeinert. Bei der Verfeinerung der Geschäftsanwendungsfälle wird für jeden Anwendungsfall ein Aktivitätsdiagramm (das so genannte Systemaktivitätsdiagramm) erstellt. Dabei werden die Aktivitäten, die durch die Anwendungsschicht realisiert werden, ermittelt. Diese Aktivitäten werden im Aktivitätsdiagramm mit dem Stereotyp <<Service-Aktivität>> gekennzeichnet, sofern sie die folgenden Charakteristika besitzen [Wit07]: Eine Service-Aktivität ist eine Aktivität der Anwendungsschicht, die als atomare Einheit verwendet wird und definierte Ein- und Ausgaben besitzt. Eine Service-Aktivität ist der größte zusammenhängende Schritt in einem Prozess, der ohne weitere Kontrollflusssteuerung von außen oder Benutzerinteraktion ausgeführt werden kann. Ein Beispiel mag verdeutlichen, wie die Verfeinerung der Anwendungsfälle aus dem Geschäftsanwendungsfalldiagramm vor sich geht. Dazu wird hier der Anwendungsfall Publikation 34

35 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung bearbeiten (siehe Abb. 3.2) herangezogen. (Die Verfeinerung der übrigen Anwendungsfälle erfolgt nach demselben Muster.) Um dies bewerkstelligen zu können, wird für den Anwendungsfall Publikation bearbeiten ein Systemaktivitätsdiagramm erstellt (siehe Abb. 3.3). Abb. 3.3: Verfeinerung des Anwendungsfalls Publikation bearbeiten 35

36 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung Abb. 3.3 stellt die Interaktion zwischen den beiden Akteuren (Benutzer und System) und die Aktivitäten, die von diesen durchgeführt werden, dar. Nach dem Anzeigen der entsprechenden Seite für die Bearbeitung der Publikationen, kann der Benutzer den Name der Publikation angeben ( Name der Publikation angeben ). Das System erhält eine Zeichenkette als Eingabe, sucht ( Publikation suchen ) die entsprechenden Publikationen und liefert eine Liste von Publikationen ( Liste der Publikationen anzeigen ). Danach kann der Benutzer aus der Liste der Publikationen die gewünschte Publikation auswählen ( Publikation auswählen ) und diese wird vom System angezeigt ( Publikation anzeigen ). Die so gewählte Publikation kann dann nach Aktualisierung gespeichert ( Publikation speichern ) oder gelöscht ( Publikation löschen ) werden. Die Aktivität Publikation suchen wird vom System durchgeführt und sie ist nicht weiter zerlegbar. Sie erfüllt die oben vorgestellten Charakteristika der Service-Aktivitäten. Somit ist Publikation suchen eine Service-Aktivität. Bei den Aktivitäten Publikation speichern und Publikation löschen handelt es sich um so genannte komplexe Aktivitäten. Diese sind solche, die vom Benutzer und vom System durchgeführt werden. Sie werden - wie bereits erwähnt - mittig zwischen den beiden Aktivitätsbereichen dargestellt. Abb. 3.4 zeigt die Verfeinerung des Anwendungsfalls Publikation löschen. Abb. 3.4: Verfeinerung des Anwendungsfalls Publikation löschen Diese Aktivität ist notwendig, um nicht mehr benötigte (oder nicht mehr verfügbare) Publikationen aus dem System zu löschen. Der vom System erledigte Löschvorgang ( Publikation löschen ) ist eine Service-Aktivität. 36

37 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung Abb. 3.5: Verfeinerung des Anwendungsfalls Publikation speichern Abb. 3.5 zeigt die Aktivität Publikation speichern. Diese Aktivität wird nach der Aktualisierung von Publikationsdaten aufgerufen, um die Modifikationen zu speichern. Die vom System ausgeführte Speicherung der Modifikationen ( Publikation speichern ) ist eine Service-Aktivität. Verfeinert man alle Geschäftsanwendungsfälle, so erhält man die folgenden Service-Aktivitäten: verlegeranlegen autoranlegen buchanlegen magazinanlegen publikationsuchen publikationspeichern publikationlöschen buchsuchen buchausleihen buchvormerken magazinsuchen magazinbestellen mahnungerstellen adressesuchen Die von den Aktivitätsdiagrammen verwendeten Ein- und Ausgaben müssen konsistent mit den Ein- und Ausgaben der entsprechenden Anwendungsfälle sein. 37

38 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung Die Service-Aktivitäten sind vollautomatische Aktivitäten des Systems z.b. LibrarySystem und sie stellen die von der Anwendungsschicht angebotenen Dienste dar. Sie haben als Ein- und Ausgabetypen die Domänenentitäten und die Instanzen der primitiven Datentypen. Die Domänenentitäten werden zu einem Domänenentitätsdiagramm zusammengestellt, in dem die Beziehungen und Kardinalitäten, die zwischen den Entitäten bestehen, dargestellt werden. Für unsere Beispielanwendung ist das Domänenentitätsdiagramm identisch mit dem Datenmodell (siehe Abb. 3.1). Nun da die Service-Aktivitäten ermittelt wurden, steht die Bestimmung der Transferobjektklassen an, die in der dritten Modellierungsphase, dem Entwurfsmodell, vorgenommen wird Entwurfsmodell Bei dem Analysemodell wurden die Systemaktivitätsdiagramme und das Systementitätsdiagramm erstellt. Letzteres bildet das Datenmodell der Anwendung. Nun werden bei dem Entwurfsmodell die oben beschriebenen Bestandteile des Analysemodells auf die Zielarchitektur der Anwendung abgebildet. Die Domänenentitäten werden auf Klassen in der Datenhaltungsschicht abgebildet. Die Service-Aktivitäten werden auf Service-Methoden in der Anwendungsschicht abgebildet. Aus den Domänenentitäten werden die Transferobjektklassen abgeleitet. So wird für jede Entität eine Transferobjektklasse erstellt, die dieselben Attribute wie die Entität hat. Die Präsentations- und Benutzer-Aktivitäten bilden jeweils die Präsentations- und Kontroller-Elemente der Präsentationsschicht. Die Anwendung hat somit eine 3-Schichten-Architektur mit einer serviceorientierten Anwendungsschicht. Die Anwendungsschicht besteht aus einer Menge von Services, die als Ein- und Ausgaben Transferobjektklassen verwenden. Sie sind also semantische Kopien der Daten der Datenhaltungsschicht (siehe Abschnitt 2.3.3). Transferobjektklassen dienen dazu, Daten zu transportieren. Sie sollten möglichst keine Funktionalitäten beinhalten. Sie bestehen aus Attributen sowie Methoden zum lesenden und schreibenden Zugriff. Die Transferobjektklassen bieten die Möglichkeit, mehr Daten zu transportieren als einfache Parameteraufrufe dies vermögen. Eine Transferobjektklasse reduziert also die Anzahl der Zugriffe auf die Persistenzschicht; dies hat eine Steigerung der Performanz des Systems zur Folge. Auch eine Kostenersparnis ist möglich, da der Zugriff auf einzelne Attribute entfernter Objekte sehr teuer ist. Darüber hinaus können Konsistenzprobleme auftreten, denn bei den einzelnen Attribut-Aufrufen eines Clients kann es vorkommen, dass ein anderer Client den 38

39 3. Beispielanwendung: Bibliothek 3.2 Modellierung der Beispielanwendung Zustand eines Attributes ändert. Eine Lösung dafür ist die Bindung aller Daten, die erforderlich sein können, in einer einzigen Transferobjektklasse, auf das mit einem einzigen Aufruf zugegriffen wird. Die Transferobjektklassen sind netzwerkfreundlich, da bei Abfrage oder Aktualisieren einer Reihe von Attribute nur ein einziger Remote-Aufruf notwendig ist. Allerdings werden in der Regel mit Transferobjektklassen mehr Daten transportiert als für die Bearbeitung einer Aufgabe nötig sind. Dieser Überfluss an Daten ist gegenüber der Latenzzeit der Remote-Aufrufe allerdings meist das geringere Übel [Fra07]. Abb. 3.6: Ablauf eines Transferobjektaufrufs [Fra07] Abb. 3.6 zeigt die Forderung von Daten (1) von einem Client an einer Komponente. Die Komponente erzeugt ein Transferobjekt (2), füllt dies mit Daten und schickt es an den Client zurück (3). Die Transferobjektklassen werden vom Domänenentitätsdiagramm aus dem Analysemodell abgeleitet. Für jede Domänenentität wird zunächst eine Transferobjektklasse erstellt, das alle Attribute der Entität beinhaltet. Domänenentitäten Vormerkung Bestellung Adresse Benutzer Publikation Mahnung Ausleihe Buch Magazin Autor Verleger Transferobjektklassen VormerkungTO BestellungTO AdresseTO BenutzerTO PublikationTO MahnungTO AusleiheTO BuchTO MagazinTO AutorTO VerlegerTO Abb. 3.7: Domänenentitäten und die entsprechenden Transferobjektklassen Abb. 3.7 zeigt die Transferobjektklassen, die aus den Domänenentitäten abgeleitet wurden. Für jede Entität wurde eine Transferobjektklasse erstellt. Die Transferobjektklassen haben denselben Namen der entsprechenden Klassen mit TO am Ende. TO steht für TransferObjekt. Verwenden Service-Aktivitäten komplexe Eingaben, d.h. Eingaben aus mehr als einer Domänenentität und die miteinander in Beziehung stehen, so wird ebenfalls die Assoziation 39