Zurück zu qinet
 Solutions & Services
Architektur

Architektur der "SW ProPlatform" (Business Application Generator der SW-Engine)

Der interne Aufbau der Programmiermaschine (SW-Engine) der "SW-ProPlatform" besteht im Wesentlichen aus dem:

Modell-Repository

Template-Repository / Business Framework

Generator-Engine


Für die zwei getrennten, datenbankbasierten Reposotory´s spricht:

Ein Repository ermöglicht die konsistente Haltung der Daten und der Beziehungen zwischen diesen Daten.

Ein datenbankbasiertes Repository ermöglicht eine Multiuser Verwendung der Daten in konsistenter Form.

Die klare Trennung der Templates von den Objekt-Modellen ermöglicht, dass z. B.:

 

-

mit dem gleichen Objektmodell Anwendungen in unterschiedlichen Architekturen und/oder Programmiersprachen erstellt werden können, z.B. Anwendungen für Java Swing, HTML-Java-Servlet, mit oder ohne EJB-Server, in .NET C#, in Cobol für Mainframe, usw. Die einmal konfigurierten, („zusammengeklickten“) fachlichen Anforderungen können per Knopfdruck in Anwendungen für unterschiedliche IT-Welten erstellt werden,

-

mit einem Template-Architektur-Satz können beliebige Objektmodelle und daraus entstehend mehrere Anwendungen umgesetzt werden: als Beispiel, mit einen Template-Satz für die Java-Web-Plattform können Anwendungen für Wertpapier-Trading, Zahlungsverkehr, CRM, Auktions-Handel, Logistiksteuerung, Produktionsplanung, usw. erstellt werden.


Model Repository

Das Model-Repository beinhaltet das Objekt-Model der zukünftigen Anwendung und weitere zusätzliche Informationen, die für die Beschreibung des Programms notwendig sind, z.B.:

Welche Suchkriterien sollen verwendet werden?

Welche Spalten hat eine tabellarische Anzeige?

Welche Felder in eine Detail-Maske sind schreibgeschützt?

Welche Sortiermöglichkeiten sollen zur Verfügung gestellt werden?

usw.



Das Modell kann durch einen Fachberater unter der Aufsicht des Object- und Datenbank-Modellierers gepflegt werden. Hier werden alle Informationen des Fachkonzeptes über die inhaltlichen Bausteine aufgebaut und abgelegt. Es können auch fachliche Anwendungen, die über andere Geschäftsprozess-Modelle (z. B.Aris oder Rational) etwickelt wurden, durch UML-Import auf Knopfdruck in Model Repository der SW-ProPlatform übertragen werden.

Die fachlichen Anforderungen , die z. B. über Plichtenheftvorgaben in Word / Powerpoint etc.(nicht strukturiert) vom Kunden dokumentiert sind, können über die Werkzeuge der SW ProEngine beliebig spezifiziert und mit einem UML-Editor als Klassenmodell erstellt werden. Das Model-Repository beinhaltet das Objekt-Modell der zukünftigen Anwendung und weitere zusätzliche Informationen, die für die Beschreibung des Programms notwendig sind. Hierbei sind keine Grenzen gesetzt: Die Vielfalt dieser Zusatzinformationen ist selbst parametrisierbar (sie sind nicht hart codiert im Generator!). Das Modell kann durch einen Fachberater unter der Aufsicht des Objekt- und Datenbank-Modellierers angepasst werden.

Ist die fachliche Anwendung im Model Repository eingepfegt, wird der Code per Knopfdruck in Verbindung mit dem Template Repository auf Basis des Business Frameworks generiert. Dabei wird bereits manuell angepasster Code berücksichtigt und unter Verwendung der im Vorfeld definierten Regeln kombiniert. In einem Round Trip Verfahren (inkrementell, iterativ) wird dieses Vorgehen solange wiederholt, bis alle Anforderungen der fachlichen Anwendung zur Zufriedenheit des Kunden fertiggestellt sind.

Template Repository

Das Template Repository beinhaltet Source-Code-Abschnitte und die Regel, wie diese Abschnitte für die Erstellung der Source-Code-Programme zu kombinieren sind. Die Erstellung, Pflege und Weiterentwicklung des Templates-Werks ist Aufgabe des System-Architekten. Obwohl diese Pflege maskengesteuert erfolgt, ist für diese Aufgabe solides IT-Knowhow notwendig. Diese Aufgabe muss einmal pro Programmiersprache und Architektur durchgeführt werden. In individuellen Fällen ist zu empfehlen, zur Unterstützung eine laufende Anwendung in der Zielsprache/ Architektur zu verwenden. Abschnitte des Anwendungscodes dieser „Beispielanwendung“ können als Templates verwendet werden.
Spezifische Programmiersprachen-Begriffe werden dabei berücksichtigt, wie:


Welche Datentypen existieren?

Wie ist der Ausdruck in der jeweilige Sprache einer Datentyps?:
(int, Integer, integer, long, usw.)

Welche Beziehungen können zwischen Objekte existieren?:
Vererbung, Kardinalitäten, Verwendung, Bezug, usw.
sind als Templates / Parameter pflegbar.)


Generell werden im Template Repository die Code-Bausteine (Source-Code-Abschnitte/Templates) verwaltet inklusive der Regeln, wie diese Abschnitte für die Erstellung der Source-Code-Programme zu kombinieren sind. Diese technischen und fachlichen Templates können individuell zusammengestellt und wiederverwendet werden. Zusätzlich können aus dem System heraus individuelle Regeln aufgerufen werden. Die Erstellung, Pflege und Weiterentwicklung des Templates-Werks sind Aufgabe des System-Architekten. Obwohl diese Pflege maskengesteuert erfolgt, ist dafür solides IT-Know-how notwendig. Mitgelieferte und flexibel erweiterbare Templates:


Mandanten-, Multi-Userfähigkeit

Mehrsprachigkeit, Internationalisierung

Benutzerführung, Navigation

Daten suchen, sortieren, anlegen, ändern, löschen

Schnittstellen für maskengesteuerte Zusatzfunktionen (z. B. Workflows)

Berichterstellung

Import / Export

Automatisierte Übernahme von UML-Fachkonzepten

Komplette Generierung von lauffähigen Anwendungen:
Programme, Deskriptionen, Ini-Dateien, Masken, Datenbankstrukturen usw.


Das Business-Framework:

(Zusammenfassung System Architektur, Java Business Framework)

Framework / Client

Frontend für Swing und HTML

Weitere Frontend-Typen modular abbildbar

Hohe Flexibilität in der Masken-Gestaltung und Benutzer-Interaktion
in einem standardisierten Aufbau

Abbildung des MVC Design Patterns

Nur View unterschiedlich zwischen Swing und HTML

Controller und Model werden wieder verwendet

Menüführung

Multi-Workflow / Multi-Task mit ein Frontend-Rahmen

Hierarchische Präsentation und Pflege der Daten

Eingabe-Workflow / Assistenten (Wizzard)

Kommunikation mit dem Server gekapselt, ersetzbar und modular erweiterbar

Klare Trennung von der Business-Implementierung

Zentrales Customizing der Maskengestaltung mit Styles



Framework / Server


Implementierung von Business-Logik in einer serviceorientierte und
wieder verwendbare Form

Trennung zwischen Business-Services und Business-Modell

Prüfung der Datenkonsistenz

Transaktionsmanagement wahlweise:

 

-

In Server, pro Business-Service oder Serviceklammer

-

Alternativ auch Steuerung der Transaktionsklammer über Client möglich

Datenhaltung:

 

-

Multidatenbank und Multidatenbank-Typ Zugriffe

-

Zugriff auf weitere Datenbanktypen modular abbildbar

-

Multiuser-Steuerung

-

Connection-Pooling (= Performance und Ressourcen sparen)

-

Automatische Erstellung und Anpassung der Datenbank-Strukturen

Die Generator-Engine

Mit der Programmiermaschine

"SW-ProPlatform" (Business Application Generator)

lassen sich für alle fachlichen Anwedungsbbereiche und Zielarchitekturen höchst komplexe Anwendungen im Modell entwickeln und per Knopfdruck generieren. Die Generator-Engine erzeugt aus dem Model-Repository und dem Template-Repositor(einschließlich dem Busines Frameworks) den Quellcode der Anwendung.

Der Quellcode wird anschließend mittels eines Compilers in eine funktioniernede Software übersetzt, um sie auf der Zielarchitektur zum Einsatz zu bringen.

Zielarchitektur der von "SW-ProPlatform" generierten Anwendungen

Client Tier
Als Frontend-Varianten werden sowohl Java Clients (basierend auf Java Swing) als auch Web-Anwendungen (basierend entweder auf einer eigenen HTML Template Engine oder auf AJAX oder auf Jakarta Struts) unterstützt.

Beide Varianten verwenden ein Model-View-Controller Pattern, wobei Model und Controller auf dem gleichen Java-Code basieren und sich Java- bzw. Web-Client nur durch unterschiedliche View-Implementierungen unterscheiden. Dadurch ist eine hohe Code-Wiederverwendbarkeit zwischen unterschiedlichen Client-Implementierungen garantiert und der Wechsel von einer Client-Variante zu einer anderen Client-Variante nur mit verhältnismäßig geringem Aufwand verbunden.

Die Kommunikation zwischen Client und Server ist abhängig von der gewählten Architektur:

Bei einem Fat-Client erfolgt die Datenhaltung in einer zentralen Datenbank,
auf die vom Client-Rechner direkt per JDBC zugegriffen wird.

Bei einem Thin-Client erfolgt die Kommunikation entweder über HTTP(S) in
der Web-Variante und über Java RMI/IIOP bei einem Java Client.


Business Tier (Server Ebene)
Der Business Tier beinhaltet die Geschäftslogik der Anwendung und wird in Form zustandsloser Services - so genannter Geschäftsprozess-Services - zur Verfügung gestellt. Alle Geschäftsprozess-Services operieren auf Geschäfts-Objekten, welche das fachliche Domain-Modell als Java Klassen-Modell widerspiegeln.

Data Tier (DB-Ebene)
Der Data Tier kapselt den Zugriff auf das jeweils eingesetzte RDBMS (Datenbank). Der Zugriff auf die Datenbank erfolgt dabei per Java JDBC.


Weitere Services des Java Business-Frameworks sind:

Email Versand:


Die Standardfunktionalität zum Versenden von Emails nutzt das SMTP Protokoll für die Versendung von Emails, welches durch den zu verwendenden Mail-Server unterstützt werden muss.

Dokumentenablage:


Die Standardfunktionalitäten für die Dokumentenverwaltung (Upload und Download) verwenden für die Speicherung der Dokumente ein File-System, in dem alle Dokumente in einem zentralen Verzeichnis abgelegt werden. Die abgelegten Dateien werden verschlüsselt, um einen nicht erlaubten Zugriff zu verhindern. In Abhängigkeit der gewählten Java Architektur muss entweder die Client-Komponente (z.B. bei einem FAT Client) oder die Server-Komponente (Web- oder Applikations-Server) direkten Zugriff auf das zentrale File-System (Verzeichnis) besitzen.





Newsflash
31.08.2010
qinet Software Factory - Onshore Entwicklung im Outtasking qinet bietet sei...

Möchten Sie mehr wissen, dann senden Sie dazu eine Email an Michael Hartmann