Seite440

• 4.4 Erweiterungs- und Verbesserungsmöglichkeiten
  • Varianten
    • GUI
    • Logik
      • Entfernter Methodenaufruf
      • Anwendungsserver
      • Anwendungsframework
      • Asynchrone Nachrichten
      • Zusatzdienste
      • Zugriff auf Persistenzzugriffsschicht
    • Persistenz
      • Methoden
      • Transaktionsunterstützungs-Verantwortlichkeit
      • Persistenzmanagement-Verantwortlichkeit
      • Zugriff und Datenzwischenspeicherung
      • Datenbank
    • Patterns, Prinzipien
  • Verbesserungsmöglichkeiten, bekannte Mängel
    • Generierte Anwendung / Referenzimplementierung
      • GUI
      • Logik
      • Persistenz
    • Generator
  • Erweiterungsmöglichkeiten
    • Allgemein
      • weitere Konfigurationsmöglichkeiten in der Generator-GUI
      • JUnit-Testfälle generieren
      • Aufteilung PIM, PSM, Generator-Templates, Generator-Konfiguration
    • GUI
    • Logik
    • Persistenz

4.4 Erweiterungs- und Verbesserungsmöglichkeiten

Varianten

GUI

• Web
• Rich-Client

Logik

Entfernter Methodenaufruf

• CORBA
• RMI
• WebServices

Anwendungsserver

• JBoss
• SUN Application Server
• Geronimo
• WebLogic
• Glassfish
• ...

Anwendungsframework

• EJB2
• EJB3
• Spring

Asynchrone Nachrichten

• JMS

Zusatzdienste

• ...

Zugriff auf Persistenzzugriffsschicht

• ...

Persistenz

Methoden

• CRUD-Operationen
• Finder-Methoden
• Kriterienabfrage
  • SQL
  • JPA-QL
  • Hibernate Criteria Object

Transaktionsunterstützungs-Verantwortlichkeit

• Anwendungs-gesteuert
• Container-gesteuert

Persistenzmanagement-Verantwortlichkeit

• Bean-gesteuert
• Container-gesteuert

Zugriff und Datenzwischenspeicherung

• direkt
• JDBC
• ORM-Mechanismus
  • EJB2 Entity Beans
  • JDO POJO
  • JPA/EJB 3.0 POJO
  • Implementierung (Hersteller, Version)
    • JPA
    • SUN
    • Hibernate
    • Bea's KODO
    • OpenJPA
    • JDO
    • ...
    • Hibernate

Datenbank

• Relational
  • PostgreSQL
  • MySQL
  • HSQL (JBoss intern)
• Objektorientiert
  • Apache Xindice

Patterns, Prinzipien

• MVC
  • diverse Variationen, z.B. Model-View-Presenter
• Dependency Injection
• Factory

Verbesserungsmöglichkeiten, bekannte Mängel

Generierte Anwendung / Referenzimplementierung

GUI

• ModelHelper benutzt noch EJB-3.0 Annotation um beim Reflektieren über die Entitätsklassen Attribute und Relationen zu identifizieren
• mehrfach geschachteltes Anlegen von Objekten (z.B. beim Anlegen eines Kunden, neue Rechnung anlegen, bei Rechnung neuen Artikel anlegen und beim Artikel neuen Artikeltypen anlegen und erst beim Speichern des Kunden werden die verbundenen Objekte in einer Transaktion angelegt)
• noch keine optimale Trennung zwischen Client-Logik und Client-View
• bessere Ereignisbehandlungsmechanismen, z.B. durch Verwendung von Action-Objekten

Logik

• noch kein Authentifizierungs- und Autorisierungsmechnismus (erfordert auch entsprechende Erweiterung beim Client)

Persistenz

• kein Locking-Mechanismus (weder optimistisch noch pessimistisch)
• keine Anwendungs-gesteuerten Transaktionen (bisher nur Containerverantwortlichkeit)

Generator

• [TODO]

Erweiterungsmöglichkeiten

Allgemein

weitere Konfigurationsmöglichkeiten in der Generator-GUI

• Datenmodell einlesen und die einzelnen Bestandteile in der GUI annotieren lassen (vergleiche dazu auch die Vorgehensweise von JAG)
• man könnte die Annotation als ALternative zu der Baumdarstellung in JAG auch über Wizards gestalten
• die gemachten Annotationen könnte man als UML-Profil(e) speichern bzw. auch laden lassen

JUnit-Testfälle generieren

• ...

Aufteilung PIM, PSM, Generator-Templates, Generator-Konfiguration

• Bessere Aufgabenverteilung zwischen Plattform-unabhängigen (PIM), Plattform-spezifischen Modell (PSM) sowie den Templates und der Generator-Konfiguration
• momentan ist nur ein Modell für die Darstellung von Entitäten, deren Eigenschaft sowie deren Beziehungen (Assoziation, Vererbung) untereinander vorgesehen, es gibt nur ein schlichte Auswahl der einzusetzenden Technologie, alle anderen Aspekte sind in den Templates versteckt -> es existiert somit explizit kein PIM und PSM (als PIM könnte man momentan die Konzepte von EMF Ecore verstehen, die im Kontext der Generator-Anwendung in den Kern-Templates interpretiert werden, und das PSM steckt in den Templates, speziell in den AOP-Templates, in denen definiert ist, welche Plattform-spezifischen Änderungen und Ergänzungen an den Kern-Templates zu machen sind
• für die zukünftige Weiterentwicklung ist zu überdenken, welche Bestandteile der Templates explizit in das Plattform-unabhängige und in das Plattform-spezifische Modell auszulagern sind
• bei der Auslagerung bzw. der Einführung neuer Konzepte in die Modelle sollte man sich fragen
  • wer ist die Zielgruppe des Generators
  • • welche Einflussmöglichkeiten auf den Generierungsprozess sind erwünscht (vor allem auch in technischer Hinsicht)
    • welches (technologisches) Wissen kann vorausgesetzt werden
  • welche Konzepte sind variabel, welche sind konstant (und müssen daher nicht unbedingt explizit im PIM/PSM gemacht werden)
  • bei welchen Konzepten ist Beeinflussbarkeit relevant: zu viele Konzepte und Einstellmöglichkeiten machen PIM und PSM unübersichtlich (und anfällig für Fehlkonfigurationen), bestimmte Dinge sollten daher konstant in den Templates außerhalb der Beeinflussung festgelegt werden
• Aspekte, die man auslagern bzw. neu einführen sollte (vergleiche dazu auch Taylor MDA)
  • GUI
  • Seitennavigation explizit festlegen
  • Einfluss auf zuverwendende Sichtelemente bei den Attributen der Entitäten (Alternativen, zusätzliche Einstellungen, Icons, Farben, ...)
  • ...
  • Logik
  • Services explizit modellieren (entweder als eigenes Modell oder als Erweiterung des bisherigen Modells)
  • Benutzerrechte der Services / Service-Methoden via Annotation festlegen
  • ...
  • Persistenz
  • Attribut einer Entität mit ID annotieren oder einer Entität die Verwendung einer ID annotieren
  • anzuwendende Validatoren für ein Attribut annotieren
  • Formatierung für ein Attribut festlegen
  • ...

GUI

• MyFaces statt Swing verwenden: man könnte an Stelle des Abeille Forms Designer ein Werkzeug wie TIBCO General Interface verwenden

Logik

• die Templatierung der Manager-Klassen, die sich bisher im Client-Cartridge befinden, sollte man besser der Logik-Cartridge zuordnen

Persistenz

• ...

---

weiter zu 4.5 Neuerungen in openArchitectureWare 4.2
zurück zu 4.3 Literatur
zurück zu 4 Implementierung
zurück zu [FrontPage]