10. Werkzeuge für den objektorientierten Entwurf und Wiederverwendung

Transkript

1 10. Werkzeuge für den objektorientierten Entwurf und Wiederverwendung SEW, Prof. Uwe Aßmann Modell-Transformation SEW, Prof. Uwe Aßmann 2

2 Modellgrenzen am Beispiel INNOVATOR Innovator kann gleichzeitig für Analyse-, Entwurfs- und Implementierungsmodelle eingesetzt werden, sowie für Transformationen dazwischen Prof. U. Aßmann, SEW Model Driven Architecture (MDA) SEW, Prof. Uwe Aßmann 4

3 MDA-Transformationsprozess Ziel: Aus plattformunabhängigem (independent) Metamodell PIM sind mittels Regeln, Techniken plattformspezifi sche (specifi c) Modelle PSM zu entwerfen, zu generieren, zu implementieren oder zu portieren, um neue objektorientierte Anwendungen für eine bestimmte (Komponenten-)Plattform zu erhalten. Ein weiteres Ziel von MDA ist die Integration solcher Technologien wie CORBA, J2EE,.Net und XML als Plattform. Unter einem Modell wird die Repräsentation einer Funktion, einer Struktur oder das Verhalten eines Systems verstanden, die modellgetrieben auf eine bestimmte Plattform transformiert werden sollen. Source Language depends upon Transformation Specifi cation depends upon Target Language defi ned in defi ned by defi ned in Source Model Transformation Target Model PIM PSM Quelle: Kleppe, A., Warmer, J., Bast, W.: MDA Explained - Practice and Promise of the Model Driven Architecture; Addison Wesley 2003 (Draft ) Prof. U. Aßmann, SEW 5 PIM und PSM gemäß der MDA Für die unterschiedlichen Abstraktionsebenen PIM und PSM stehen verschiedene Beschreibungsmittel zur Verfügung: Fachkonzept auch CIM (Computation independent model) Plattformunabhängiges Modell (UML, OCL, XMI) Plattformspezifi sches Modell Basiskomponenten (JB) Steuerungskomponenten Infrastrukturkomponenten (EJB, CCM, COM+,.NET) Anwendungskomponenten Programmierung (oop) PIM PSM Ein PSM berücksichtigt die jeweilige Basistechnologie, auf der ein PIM zum Einsatz kommen kann (CORBA-Broker,.NET-Spezifi ka oder das Web-Service-Protokoll SOAP). Auch PSMs können mit der UML modelliert werden. In jedem Fall werden aus den PSMs die Codegerüste erzeugt, die die Komponenten-Entwickler dann weiter bearbeiten. Quelle: Warum JANUS MDA und MDA JANUS ist; Whitepaper der Firma otris Software AG Dortmund; URL: Prof. U. Aßmann, SEW 6

4 Das MDA-Metamodell <<basiert auf>> PIM Mapping Techniken Mapping von PIM zu PIM UML <<dargestellt mit>> 1..n <<beschrieben mit>> PIM 1..n <<unabhängig von>> MOF <<dargestellt mit>> Metamodel 1..n Mapping von PIM zu PSM Refactoring vom PSM zu PIM andere Sprachen <<dargestellt mit>> 1..n 1..n <<beschrieben mit>> 1..n PSM <<hängt ab von>> Infrastruktur <<basiert auf>> 1..n PSM = plattformspezifi sches Modell PSI = plattformspezifi sche Implementation PSM Mapping Techniken Mapping von PSM zu PSM Transformationen bezeichnet man auch als Abbildungen (mappings). Mapping von PIM zu PIM schafft neue Business Viewpoints, von PSM zu PIM Abstraktionen aus plattformabhängigen Implementierungen und zwischen PSM weiteren Verfeinerungen oder Zielplattformen. Prof. U. Aßmann, SEW 7 Model Management In der MDA müssen Modelle verwaltet werden: Modellalgebren. Lookup. Dif, comm, union, compose Versionsmanagement Konfgurationsmanagement Das führt auf Modellinfrastrukturen, Beispiel ModelBus Verteiltes Repository für Modelle Prof. U. Aßmann, SEW 8

5 Model Managemant Funktionen Tools im ModelBus Tool Service Parameter Multiplizität Type UML- fi ndclass ClassName in [1..1] primitivetype (String) Repository Class out [1..1] specifi cmodeltype (Foundation::Core::Class) fi ndpackage PackageName in [1..1] primitivetype (String) Package out [1..1] specifi cmodeltype (Model_Management::Package) UML to transform sourcemodel in [1..*] specifi cmodeltype EJB (Model_Management::Package) targetmodel out [1..*] specifi cmodeltype (EJB:: EjbComponent) Code generatesingle EJBComponent in [1..1] specifi cmodeltype Generation Component (EJB:: EjbComponent) generate EJBComponent in [1..*] specifi cmodeltype Components (EJB:: EjbComponent) Quelle: Blanc, X., Gervais, M.-P., Sriplakich, P.: Model Bus: Towards the Interoperability of Modelling Tools; in Aßmann, U. u.a.: Model Driven Architecture, Springer Verlag 2005 Bewertungsaspekte von MDA-Tools Prof. U. Aßmann, SEW 9 Unterstützung der Sprachen UML 2.0, OCL, XMI, CWM (MOF 2.0-basiert) Import, Export und Validierung von Modellen auf Basis ihres Austauschs mit XMI 2.0 Mapping zu einer Programmiersprache wie z. B. JMI Model-to-Model Mapping bzw. Transformation (z. B. PIM zu PSM) Model-to-Code Transformation (PIM zu PSI) Validierung der Modelle sowohl für Im-/Export als auch für die Transformation Erweiterungsmöglichkeiten der UML-Profi le durch explizite Metamodellierung sowie Modellprüfung Forward-, Reverse- bzw. Roundtrip-Engineering auf der Code-Ebene in Protected Regions Unterstützung zur Generierung grafi scher Benutzungsschnittstellen Automatische Generierung der Dokumentation Modellierung von Testfällen und automatische Generierung der Testdaten Eigenständige MDA-Tools, wenn sie (Meta-)Modellierung, Transformation und Code- Generierung unterstützen MDA-Suite, wenn sie CASE- bzw. UML-Umgebungen integrieren Quelle: Petrasch, R., Meimberg, O.: Model Driven Architecture - eine praxisorientierte Einführung in die MDA; dpunkt-verlag 2006 Prof. U. Aßmann, SEW 10

6 Werkzeugfunktionen am Bsp. ArcStyler Object Modeler erfasst Anforderungen unabhängig von Plattform (funktionale, essentielle Anforderungen) Basis CRC-Cards Technologie Pattern Refi nement Assistent überführt Fachmodell interaktiv in PIM UML-Modell (Basis MagicDraw oder Rational Rose) mit Annotation der essentiellen Design-Entscheidungen Verfeinerung des Fachmodells top down in untergeordnete UML-Diagramme und Quellcodegenerierung ebenfalls mit UML-Tool (MagicDraw) Codevervollständigung und Optimierung für jeweiligen Applikationsserver mit Cartriges und Tool ArcStyler von Interactive Objects Software GmbH Freiburg Komponentengenerierung für Oberfl äche sowie weitere Projekt- und Konfi gurations- dateien mit JBuilder. Schnittstelle zu IDE ist Standard Ant Build Process Datenbankgenerierung über Skripte zum Erstellen der DB-Schemas möglich. Das Werkzeug ArcStyler ist im Zusammenspiel mit MagicDraw (oder Rational Rose...) ein leistungsfähiges Werkzeugsystem(MDA-Suite), mit dem sich zum Beispiel J2EE- Applikationen gemäß den Konzepten der MDA entwickeln lassen. Quelle: Versteegen, G.: Wege aus der Plattformabhängigkeit - Hoffnungsträger Model Driven Architecture; Computerwoche 29(2002) Nr. 5 vom 1. Febr Vorgehen und Unterstützung beim ArcStyler Prof. U. Aßmann, SEW 11 Prof. U. Aßmann, SEW 12

7 Cartridges und generierte Artifakte Quelle: Butze, D.: Entwicklung eines Praktikums für die werkzeugestützte Softwareentwicklung nach der Model-Driven-Architecture; Großer Beleg an der Fakultät Informatik der TU Dresden 2004 Prof. U. Aßmann, SEW 13 Kurzbeschreibung weiterer MDA-Tools Name Typ Austauschform. Zielsprachen IDE integr. IBM Rational Suite XMI, Rose Java, C++ Eclipse Software Architect Compuware Suite XMI, JDBC, Java, SQL, VisualStudio, OptimalJ XML Schema, XML JBuilder, versch. IDL Eclipse AndroMDA Frame- XMI Java, SQL, Eclipse work anpassbar Open Frame- XMI beliebig durch Eclipse Architecture work Anpassung Ware BITplan Frame- XMI Java, Obj. Pascal, Eclipse, smart work C, C++, C#, Cobol, Ultra Edit, Generator IDL, SQL, Vis. Basic VIM Quelle: Petrasch, R., Meimberg, O.: Model Driven Architecture - eine praxisorientierte Einführung in die MDA; dpunkt-verlag 2006 Prof. U. Aßmann, SEW 14

8 10.3 Werkzeuge zur Arbeit mit Komponenten und Patterns SEW, Prof. Uwe Aßmann 15 Anforderungen an Werkzeuge zur Arbeit mit Komponenten Die Idealvorstellung wäre ein Software Information System (SIS) mit folgenden Eigenschaften: Beschreibung von vorhandenen Komponenten (im Repository) Beschreibung von vorhandenen Komponentenframeworks spezifisches Wissen(Expertensystem) für verschiedene Anwendungsbereiche (domain knowledge) Werkzeuge zur Navigation und Komponentenauswahl(Component Retrieving) strukturierte Editoren zur visuellen Zusammenstellung von Komponenten Assistenten(Wizards) zur Generierung von Grundgerüsten an Implementationscode Transformatoren zur Übertragung einer Komponente in eine andere Technik Generatoren zur Automatisierung der Implementations- und Codierungsphase Scriptsprachen zur Verfeinerung bzw. Anpassung bereits fertiggestellter Komponenten Werkzeuge zum automatisierten Zusammenbau (Montage) Quelle: Griffel, F.: Componentware - Konzepte und Techniken eines Softwareparadigmas; dpunkt.verlag 1998 Prof. U. Aßmann, SEW 16

9 Werkzeugaufgaben am Beispiel objektorientierter Klassenbibliotheken oder Frameworks Visualisierung von objektorientierten Komponenten- oder Programmstrukturen statisch (Zustandsbeschreibung der Attribute) dynamisch (Verhaltensbeschreibung der Methoden) statischen objektorientierten Strukturen Codestruktur Datenstrukturen Objektstrukturen Kontrollstrukturen Methodenstrukturen Objektstrukturen zwischen internen Attributen v. Objekten externen Relationen zw. Obj. Darstellen, Navigieren entlang Relationen, Vergrößern, Verschieben Methodenstrukturen { des Fokus interne Kontrollstruktur der Operationen externer Aufruf von Methoden bzw. Operatoren objektorientiertem Programmcode Einrückdiagramme (Verschachtelungen mit Farbe, Schriftarten) Tempates (formatierte Eingabeschablonen) Quelle: Herczeg, J.: Methoden und Werkzeuge zur visuellen objektorientierten Programmierung, Diss. Universität Stuttgart 1995) Prof. U. Aßmann, SEW 17 Werkzeugaufgaben am Beispiel objektorientierter Klassenbibliotheken oder Frameworks(2) Visualisierung von dynamischen objektorientierten Strukturen Datenfl ußmodell Folge auf Objekt angewandter Operatoren und Attributwertänderungen Kontrollfl ußmodell Abfolge von Nachrichten(Nachrichtenfl uß) zu Methoden- oder Funktionsaufrufen Ereignissen und Zuständen textuelle Protokollierung ihres Eintreffens (Tracing) Abfolge von Momentaufnahmen (Snapshots) sich ändernden Zuständen (Animationen und Simulationen) Methoden- und Funktionsinterpretation Darstellung Methodendefi nition und Modifi kation Inspektion beteiligter Objekte bzw. Argumente Darstellung der Aufrufhierarchie als Keller (Aufruf-Stack) Programmausführung Eintreten in gesetzte Haltepunkte (Breakpoint) explizite Programmunterbrechung durch Nutzer (Interrupt) Auftreten eines Programmfehlers Fortsetzen und Abbrechen des Programmablaufs Quelle: Herczeg, J.: Methoden und Werkzeuge zur visuellen objektorientierten Programmierung, Diss. Universität Stuttgart 1995) Prof. U. Aßmann, SEW 18

10 Werkzeug-Grundtypen für objektorientierte Komponenten- bzw. Klassenbibliotheken Editoren: Erstellen und Modifi zieren statischer Komponentenstrukturen Textdarstellung mit speziellen Visualisierungstechniken wie Ein- rückdiagrammen und Templates Browser: Visualisierung von externen Komponenten-, Objekt- und Methodenstrukturen Navigieren und Explorieren in diesen Strukturen Erlaubte Manipulationen mit speziellen graphischen Editoren möglich Inspektoren: Visualisierung und Modifi kationen interner Komponentenstrukturen Darstellung und Modifi kation von Attributen und Instanzvariablen Tracer: Visualisierung dynamischer Komponentenstrukturen, wie Funktions- und Methodenaufrufe Navigation in dynamischen und auch statischen Komponentenstrukturen Weitere einzusetzende Werkzeuge siehe Klassen von CASE-Tools(1. Vorl.) Quelle: nach Herczeg, J.: Methoden und Werkzeuge zur visuellen objektorientierten Programmierung, Diss. Universität Stuttgart 1995 Anwendungs- und Komponenten-Entwicklung: buy or build? Prof. U. Aßmann, SEW 19 Specifi c Business Requirements APPLICATION PROCESS SOLUTIONS Sow Reuse Harvest Services Generic Business Requirements COMPONENTS COMPONENT PROCESS Quelle: SELECT Enterprise; Demo Prof. U. Aßmann, SEW 20

11 Aufgaben des SELECT Component Manager Hilft Nutzern, Designern und Entwicklern Komponenten zu verwalten, zu publizieren und Wiederzuverwenden mittels Bereitstellung folgender Funktionen: Publizieren neuer Komponenten(Anforderungen, Spezifi kation, Interfaces) zum Zwecke der Wiederverwendung Speicherung von Informationen über ein breites Gebiet von Komponenten COM, CORBA, EJB und aller eingeschlossenen Funktionen Verwaltung der Komplexität der Versionsbeziehungen und aller Abhängigkeiten zwischen den Komponenten Wiederauffi ndung(sophisticad) aller Komponenten mit einer universellen Suchmaschine einschließlich des Zugriffs zu ihnen entsprechend den spezifi zierten Anforderungen Verwalten der Repositories im Netz, Nutzerregistrierung und Zugriffssteuerung zur Sicherung einer automatisierten Komponenten-Änderung, ausgelöst durch Sicherung der Verwaltung aller Komponentenbeschreibungen, wie Hilfe-Files, Installetionsanleitungen direkt aus dem Repository Visualisierung der Komponentenabhängigkeiten und der Komponentenversorgung mittels Browsern und Drag-and-Drop Entwurf und Verwaltung der Komponentenverbreitung mittels automatischer Generierung von UML-Diagrammen. Quelle: Alip, M.: Entwicklung eines Werkzeug-Praktikums zur komponentenorientierten Softwareentwicklung; Diplomarbeit an der Fakultät Informatik der TU Dresden 2004 Prof. U. Aßmann, SEW 21 Zusammenspiel von SELECT Enterprise und Component Manager CONSUME (Application Development) Business Process Model - Process Hierarchy Diagram - Process Thread Diagram MANAGE SUPPLY (Component Development) Use Case Model - Use Case Diagram - Object Collaboration Diagram Use Case Model Use Case Diagram Architecture Model Interface Design Class Model - Object Sequence Diagram - Class Diagram - State Diagram Architecture Diagram Code Generation Synchronization Component Model - Object Sequence Diagram - Component Interface Diagram Publish Specifi cation Use Specifi cation SELECT Component Manager Publish Component Java Synchronizer Built Component UI Design & Code Application Quelle: SELECT Perspective: Hilfethemen Prof. U. Aßmann, SEW 22

12 Vorgehensmethodik zur Wiederverwendung mit dem Component Manager Quelle: SELECT Perspective: Hilfethemen Prof. U. Aßmann, SEW Funktionen des Source Code Engineering am Beispiel SNiFF+ SEW, Prof. Uwe Aßmann 24

13 Entwicklungsumgebung SNiFF+ SNiFF+ ist offene, erweiterbare und anpassbare Cross-Programmierumgebung mit dem Hauptziel, für große Multi-Entwickler-Projekte eine effektive Unterstützung ein-schließlich einer komfortablen, adaptierbaren Benutzungsschnittstelle bereitzustellen. Codeverständlichkeit und Browsing Filterungs- und Visualisierungstechniken helfen die Vielzahl von Files, Symbolen und Codezeilen zu beherrschen, indem eigene sprachsensitive und fehlertolerante Parser geboten werden. Alle Code-Änderungen werden durch Browser-Tools direkt angezeigt, so daß eine Recompilierung unnötig ist. Projekt- und Code-Verwaltung für Teams Ein leistungsfähiges Projekt- und Arbeitsplatz-Konzept gestattet Bearbeitung sehr großer Projekte und effektive Kooperation in Teams. Eine effi ziente Replikation und ein File-Sharing mit Versionskontrolle(VC) zwischen den Nutzern wird unterstützt. Werkzeug- und Steuerintegration Die Integration externer Werkzeuge (vom Editor bis zum VC-Tool) wird mittels eines Adapters am SNiFF+ -Interface gewährleistet. Cross-Plattform Unterstützung Arbeit in heterogenen Entwicklungsumgebungen und einfache Portierung auf andere Plattformen (integriert in das Projektmanagement). Quelle: Hutschenreiter, J.: Werkzeuggestützte Entwicklung und Verwaltung größerer Softwareprojekte, Fa. CSC Ploenzke AG; Vortrag der GI-Regionalgruppe Dresden am Source Code Engineering mit SNiFF+ Prof. U. Aßmann, SEW 25 Source Code Engineering bildet die Grundlage, um Quellcode schnellstmöglich zu bearbeiten und Softwareprojekte ständig aktuell zu halten: schnelles Erfassen und Verstehen komplexer Abhängigkeiten und Bezie-hungen im gesamten Quellcode (mittels Browsern und Filtern) leichte punktgenaue Navigation durch Tausende von Files und Millionen Lines of Code (z.b. mit Browsern und Such-Tools) detaillierte Analyse innerhalb quasi unendlicher Listen Auffi nden aller rufenden und gerufenen Funktionsbeziehungen, des Lesens oder Schreibens von Variablen als Basis der Wiederverwendung bzw. des Reengineerings existierenden Quellcodes kürzere Entwicklungszyklen einheitliche Entwicklung in Multilanguage Environments schnellere, unterstützte Einarbeitung der (Anfänger-)Entwickler in neue und existierende Projekte Organisation einer effektiven Teamarbeit und -verwaltung für große Projekte Leicht zu bedienende und konsistente Werkzeuge auf möglichst vielen Plattformen (Windows und unterschiedliche UNIX-Derivate) Eingliederung von Dateisystemen als Unterprojekte wird gestattet. Prof. U. Aßmann, SEW 26

14 SNiFF+ Gesamtüberblick Projekt- Management Quellcode-Verstehen und -Browsen Entwicklung Launch Pad Symbol Browser Hierarchy Browser Class Browser Cross Referencer Retriever Include Browser Editor oder externer Emacs Code- Aufbau Versions- und Konfi gurations- Management Projekt Editor Confi guration Manager Diff/Merge Tool SNiFF+ Versions- und Konfi gurations- Systemadapter Interne Daten- und Steuerungsintegration Zentrales Data Repository Access Interface Build (Make) und Compiler Adapter SNiFF+ Symbol- Tabelle API Shell Debugger Documentation Editor Parser Adapter Dokumentations- Aufbau Debuggen Externes Versionsund Konfi gurations- Managementtool sniffaccess CASE-Tools sniffappcomm... Debugger... Make und Compiler... sniff parser Quelle: entnommen aus Online-Hilfe von SNiFF+: Index-Punkt SNiFF+ Architektur - SNiFF+ Umgebung Hersteller: Wind River Inc., Alameda, California, USA Hinweis: Keine Browser für die dynamische Sicht vorhanden! Prof. U. Aßmann, SEW 27 S N i F F + - Werkzeuge: PE (1) Project Editor (PE) verwaltet Projekt-Dateien und -Attribute (einschl. Laufzeitparameter der Entwicklungsumgebung) auf Basis einer abstrakten File-Level-Sicht in einer natürlichen hierarchischen Form(Projekt, Teilprojekt, Filetypen (Quellcode, Binär-, Make-, Test,- Dok.-Files usw.) und gestattet damit eine exakte und komplette Defi nition von Projektelementen. Der PE ist die zentrale Zugriffsbasis für die Arbeitsumgebung auf File-Ebene und Ausgangspunkt für die (z.b. sensitiven) Aufrufe weiterer SNiFF+-Tools (z.b. Browser). hilfreiche leistungsfähige Filter Verwaltete Datei-Objekte (hier Projekt OfficeApp ) Projekt-Baum Abbildung: Project Editor Prof. U. Aßmann, SEW 28

15 S N i F F + - Werkzeuge: HB (2) Hierarchy Browser zeigt die Klassen-Vererbungs-Hierarchie und stellt bei direktem Quellcode-Bezug Filtermechanismen zur Auswahl der Klassen und Hierarchieanzeige-Eigenschaften bereit. Abbildung: Hierarchy Browser Interface (runde Ecken, schräge Schrift) Klasse ( normal ) abstrakte Klasse (schräge blaue Schrift) implementierende / erbende Klassen anonyme Klassen (OuterClassName$InnerClassName) sensitiver Java-Quelltext mit ausgewählter Klasse Prof. U. Aßmann, SEW 29 S N i F F + - Werkzeuge: CB (3) Class Browser liefert zusammenfassenden Überblick über alle Klassen- Informationen (ähnlich Symbolbrowser) im Zusammenspiel mit Filtermechanismen. Abbildung: Class Browser Methoden Attribute Indikatoren ( Kürzel = dienen der Typisierung, Farben = Sichtbarkeit, Schrägbalken = virtuelle Methode, Foto-Ecken = Überschreibe-Modus, Schrift = schräg>abstrakt, fett>mit Teilen, die Filterkriterien entsprechen ) Prof. U. Aßmann, SEW 30

16 S N i F F + - Werkzeuge: SB (4) Symbol Browser liefert Überblick über alle Symbole (s. Class Browser), wie Variable, Funktionen, Methoden, Klassen, Schnittstellen usw. im Quellcode (auf File- od. Projekt-Ebene). Durch das Einschalten von Filtern (z.b. Symboltyp bzw. andere Kriterien) wird die Code- Durchsuche erleichtert. Packages Abbildung: Symbol Browser Prof. U. Aßmann, SEW 31 S N i F F + - Werkzeuge: CR (5) Cross Referencer (ähnlich HB) ermittelt alle Arten unterschiedlicher Bezugnahmen (Komponenten- und Aufruf-Beziehungen in beide Richtungen) und stellt sie für Auswertungen (z.b. Auswirkung von Codeänderung im Projekt) bereit. (De-)Konstruktor- Methode Klasse referenziert -Pfeil referenziert von -Pfeil (allg.) Methode genutzt als Komponententyp ( H -Relation = hat ein ) sensitiver Java- Quelltext mit ausgewählter Methode Prof. U. Aßmann, SEW 32

17 Tool Integration Framework with SNiFF+ Möglichkeit der Integration unterschiedlicher Werkzeuge, wie Editoren, Compiler, Debugger, Konfi gurationsmanagement und Versionssteuerungs-tools je nach Ausprägung bestimmter Gewohnheiten der Entwickler. Mit der offenen graphischen Benutzungsschnittstelle(GUI) können wahl-weise auch unterschiedliche Interfaces zu anderen Plattformen und wichti-gen Tools einbezogen werden. Es wird eine Aufbau-Verwaltung(build management) geboten auf Grundla-ge der Unterstützung komplexer Projekte(Proj.-Attribute), der Teamarbeit sowie der parallelen Verwaltung von Konfi gurationen(automatically make) und Plattformen. Möglichkeit der Kopplung mit CASE-Tools insbesondere für die frühen Phasen zur Integration grafi scher Spezifi kationen in die Entwicklungsum-gebung. Einbeziehung von Prototyping-Werkzeugen, sogenannten Rapid Appli-cation Development(RAD)-Tools zur Umsetzung einer partizipativen Pro-jektentwicklung ausgehend von der Benutzungsschnittstelle. Nutzung des Remote Control Interface zum adaptergesteuerten Zugriff auf externe Tools auf entfernten Plattformen. Quelle: URL: Hersteller: Wind River Inc., Alameda, California, USA Prof. U. Aßmann, SEW 33 End Prof. U. Aßmann, SEW 34

18 Vorschlag eines Werkzeugkastens für den musterbasierten Entwurf von Framework-Applikationen 2 Class Hierarchy Browser Hypertexteditor muster-basiertes Dokumentationstool Entwurfsmuster- Beschreibung (am Beispiel von ET++) muster-basierte Strukturbeschreibung Grafi keditor Hypertexteditor Source Code Browser Source Code Browser Hypertexteditor muster-basiertes Struktur- Dokumentationstool Entwurfsmuster- Beschreibung 3 muster-basierte Komponentenbeschreibung elektronischer Entwurfsmusterkatalog Entwurfsmuster- Beschreibung 1 muster-basierte Strukturbeschreibung muster-basierter Entwurfstool 4 Grafi keditor Hypertexteditor Source Code Browser Quelle: Göpfert, A.: Software-Entwicklungswerkzeuge zur Nutzung von Design-Mustern; Diplomarbeit TU Dresden, Fakultät Informatik 1996 Notwendigkeit der oo-transformation Prof. U. Aßmann, SEW 35 Benötigte Attribute zur Implementation der vorhandenen (bi- oder unidirektiona- len) Objektassoziationen? Notwendige Attribute zur Umsetzung von Aggregationsstrukturen (Ist für Teilobjekt die Kenntnis des Gesamtheitsobjektes notwendig?) Sollen ableitbare Attribute oder zusätzliche Objektverbindungen modelliert werden (Effi zienz)? Welche Abstimmung der Objekte (synchron oder asynchron) wird verlangt? Braucht man nebenläufi ge Prozesse? Notwendige Klassen zum Erzeugen persistenter Objekte, zum Speichern und zur Kommunikation mit einer Datenbank? Realisierung als zentrales oder verteiltes System? Wie kommen Nachrichten im verteilten Fall an die richtige Stelle? Nutzung welcher Komponententechnologie? Notwendige Klassenobjekte zur Ausnahme- und Fehlerbehandlung (Administration)? Notwendige Klassen für Benutzungsschnittstelle und Kommunikation mit anderen Systemen (Infrastruktur)? Bei Zerlegung des entstehenden Programms in eine Modulstruktur, welche (Übersetzungs-)Abhängigkeiten bestehen zwischen den Moduln? Quelle: Rumbaugh, J. u. a.: Objektorientiertes Modellieren und Entwerfen; Hanser-Verlag 1994, S.140 Prof. U. Aßmann, SEW 36

19 Beispiel Application Framewerk Eclipse Hergestellt durch Open Source-Gemeinde unter Führung von IBM und Mitwirkung von Borland, Oracle, Together, Rational (ca. 150 Mitglieder) aber zunächst ohne Sun (Gegensatz zu AWT, Swing) und Microsoft Stellt eine Bibliothek wiederverwendbarer Software-Komponenten in Form eines umfang-reichen Frameworks für Java-Applikationen zur Verfügung Enthält ein Anwendungsframework JFace mit einfachen Funktionen zur effi zienten Implementierung von GUI-Benutzeroberfl ächen auf der Basis von SWT (Standard Window Toolkit), eines GUI-Framework basierend auf der MVC-Architektur Vorgefertigte Actions defi nieren eine Semantik für Benutzeraktionen Bietet eine umfangreiche Plugin-Architektur, in der eine Vielzahl von Plugins verschiedener Entwickler, z.b. die Java-IDE selbst, aber auch Plugins für C++, COBOL, RPG(in Vorbereitung) bereitgestellt werden Zur Erstellung von Eclipse-Projekten werden eine Vielzahl von Werkzeugen, wie textbasierte und grafi sche (implementierbare) Editoren statische und dynamische Browser Viewer zur Visualisierung der internen Objektstruktur und der dynamischen Objektzustände und viele weitere Werkzeuge zur Verfügung gestellt Prof. U. Aßmann, SEW 37 JFace und Eclipse externe Werkzeuge Quelle: Daum, B.: Java-Entwicklung mit Eclipse 2 Anwendungen und Plugins implementiernen mit SWT und JFace; dpunkt.verlag2003 Prof. U. Aßmann, SEW 38

20 Hauptwerkzeuge für die Eclipse-Plattform Java-Entwicklungswerkzeuge(JDT): Worbench-Editoren wie - Text-Editor - Schema-Editor (für XML) - graphischer (composition) Editor Browser wie - Hierarchie-Browser - Package Explorer (Navigator) - weitere konfi gurierbar Browsing-Perspektive erlaubt Sichten auf Projekte, Packages, Typen und Methoden bzw. Felder Viewer - JUnit-Viewer - Property-Viewer - CVS Repository Viewer - Search-Viewer - weitere anlegbar über JavaPackage als Table- oder Tree-View z.b. zum Visualisieren von Aufbau, Filterung, Sortierung sowie Aktualisierung von Listen, Tabellen und Bäumen - Outline-Viewer (an die Workbench lassen sich mehrere Fenster oben und unten wie vom Nutzer gewünscht andocken) Plug-In-Entwicklungsumgebung(PDE): erlaubt die Einbindung unterschiedlichster Werkzeuge für Softwareentwicklung wie Together, MagicDraw, JavaCC, ClearCase, JellySWT(XML-basierte Scriptsprache für SWT) und viele andere Prof. U. Aßmann, SEW 39