Seite232

• 2.3.2 Nicht-funktionale Anforderungen an die zu generierende Anwendung
  • Bedienbarkeit
    • Beschreibung
    • Umsetzung
  • Änderbarkeit der Namensräume und Bezeichner
    • Beschreibung
    • Umsetzung
  • Qualität des generierten Codes
    • Beschreibung
    • Umsetzung
  • Änderbarkeit und Erweiterbarkeit der generierten Anwendung
    • Beschreibung
    • Umsetzung

2.3.2 Nicht-funktionale Anforderungen an die zu generierende Anwendung

Folgende Nicht-funktionalen Anforderungen beziehen sich auf die mit dem Generator auszuliefernde Referenzimplementierung einer Swing-, EJB3.0/JBoss- und JPA/Hibernate-Cartridge-Kombination, mit der sich eine Beispiel-3-Schicht-Anwendung mit eben diesen in den Cartridges umgesetzten Technologien generieren lässt.

Bedienbarkeit

Beschreibung

• einfache Installation auf Client und Server
• Client verfügt über intuitiv bedienbare Benutzeroberfläche
• Antwort-Zeit-Verhalten der Anwendung bewegt sich in den Bereichen herkömmlich erstellter 3-Schicht-Anwendungen

Umsetzung

• die Server-Anwendung wird als ear-Datei ausgeliefert, die Client-Anwendung ist eine ausführbare jar-Datei
• im Client wird eine mit Java Swing erstellte grafische Benutzeroberfläche verwendet

Änderbarkeit der Namensräume und Bezeichner

Beschreibung

• Namensräume in Form von Paketstruktur und -bezeichnern kann vor der Generierung festgelegt werden
• die in der Anwendung zu verwendende Bezeichner sollen dynamisch festgelegt werden können (um z.B. eine Lokalisierung der Anwendung vornehmen zu können)

Umsetzung

• im Generator kann vor der Generierung die generierende Verzeichnis- bzw. Paketstruktur festgelegt werden, bei der Generierung werden dann entsprechend die Verzeichnisse angelegt und die generierten Artfakte unter ihnen abgelegt
• in der generierten Anwendung werden für die Bezeichner Platzhalter verwendet, die konkrete Benamung wird in Property-Dateien ausgelagert, diese Property-Dateien können bei der Konfigurierung des Generators erzeugt werden, aber auch nachträglich im Dateisystem geändert und in der generierten Anwendung durch andere Property-Dateien ausgetauscht werden

Qualität des generierten Codes

Beschreibung

• Unabhängigkeit der Geschäftslogik von realisierenden Technologien und Schichten
• Lesbarkeit des generierten Codes

Umsetzung

• Verwendung von Architektur- und Entwurfsmustern bei der Umsetzung der Technologien in den Templates
• Nutzen der mit openArchitectureWare ausgelieferten PrettyPrinter, um den generierten Code in die von Code-Formatierungsregeln geforderte Form zu bringen

Änderbarkeit und Erweiterbarkeit der generierten Anwendung

Beschreibung

• Änderungen am Generierungsvorgang leicht durchführbar
• leichte Austauschbarkeit von Technologien
• Einbindung eigener manueller Klassen in die generierte Anwendung
• Änderbarkeit generierter Bestandteile

Umsetzung

• die Konfiguration des Generators lässt sich in eine externe Datei speichern und auch von einer solchen wieder laden, so dass sich Generierungsvorgänge leicht reproduzieren lassen bzw. auf Grundlage bestehender Konfigurationen leichte Änderungen am Generatorprozess vornehmen lassen
• die lose Kopplung der Schichten in der generierten Anwendung wird durch den sinnvollen Einsatz von Struktur- und Entwurfsmustern, wie beispielsweise das Business-Delegate-Muster für die Entkopplung von Präsentation und Geschäftslogik oder das Data-Access-Object-Pattern für die Kapselung des Datenzugriffs)
• manuelle Klassen können generierte Klassen aufrufen oder durch Vererbung erweitern, die Schnittstellen und die Funktionalität der generierten Klassen ist ausführlich beschrieben, so dass Fehler bei der Integration manuellen und generierten Codes vermieden werden können
• durch die ausführliche Dokumentation der Schnittstellen und Funktionalitäten der generierten Klassen auch im Gesamtkontext ist auch eine Änderung der generierten Klassen selbst möglich (obwohl nicht empfohlen, da sie bei erneuter Generierung der Anwendung überschrieben werden)

---

weiter zu 3 Entwurf
zurück zu 2.3.1 Nicht-funktionale Anforderungen an den Generator
zurück zu 2.3 Nicht-funktionale Anforderungen
zurück zu 2 Anforderungen
zurück zu [FrontPage]