<body> <p>Diese Seite benutzt Frames, die Ihr Browser nicht unterstützt.</p> </body>

Frameworks in der VFP-
Programmierung

Was ist ein Framework

Warum ein Framework?

Klassen-Hierarchie

Klassen-
Hierarchie
(siehe auch Anhang VIIa!)

Warum Klassen strukturieren?

Problemspezifische Klassen

Aspekte einer Applikation,
die in ein Framework integriert sein können

Allgemeine Elemente einer Applikation (I)

Allgemeine Elemente einer Applikation (II)

Allgemeine Elemente einer Applikation (III)

Allgemeine Elemente einer Applikation (IV)

Allgemeine Elemente einer Applikation (V)

Relation zwischen Applikation und Framework

Relation zwischen
Applikation und Framework (I)

Relation zwischen
Applikation und Framework (II)

Allgemeine Struktur
einer Applikation
(siehe auch Anhang VIIa!)

Allgemeine Struktur
einer Applikation (I)

Allgemeine Struktur
einer Applikation (II)

Allgemeine Struktur
einer Applikation (III)

Wie das Framework die Struktur unterstützt
(siehe auch Anhang VIIa!)

Wie das Framework die Struktur unterstützt (I)

Wie das Framework die Struktur unterstützt (II)

Wie das Framework die Struktur unterstützt (III)

Arten von Frameworks

Integrierte Frameworks

Komponenten-basierte Frameworks

Wie das Framework die Struktur unterstützt

| | | | | | | | |

Frameworks in der VFP-

Programmierung

| | |

n

Zusammenfassung einer Anzahl von Klassen und

Programmen, die zur Erstellung einer Applikation

notwendig sind:

| | | | |

Datenbankschema

FoxPro Basisklassen

non visual classes

visual classes

problem-spezifische

Klassen

| |

Standard-Dateien

Header-Files

Menü-Vorlagen

Standard-Module

|

| |

Ende der Bildschirmpräsentation. Zum Beenden klicken.

Frameworks in der VFP-
Programmierung

|
| Zusammenfassung einer Anzahl von Klassen und Programmen, die zur Erstellung einer Applikation notwendig sind:

Was ist ein Framework

|

Die Zusammenfassung aller in einem
Framework enthaltenen Programme plus
der abgeleiteten Instanzen der verwendeten Klassen bilden das aktuelle Programm.

Warum ein Framework?

|

Ein Framework ermöglicht die schnellere
Erstellung von Applikationen.

Applikationen haben eine größere Stabilität, weil man auf fertige geprüfte
Module zugreift.

Durch objektorientierte Porgrammierung OOP entsteht eine höhere Wieder-Verwendbarkeit der Module und eine
größere Flexibilität.

Klassen-Hierarchie

| |
| Je mehr OOP, desto besser!
| Jede objektorientierte Programmierung basiert auf einer Klassenhierarchie:
| Visual FoxPro Grundklassen
| Eigene Basisklassen
| Generische Grundklassen
| Applikationsklassen

Spezifische, auf das Programmier-Problem
bezogene Klassen

| OBJEKTE

Klassen-
Hierarchie
(siehe auch Anhang VIIa!)

Warum Klassen strukturieren?

|

Eine fest definierte Struktur macht es einfacher, den Vererbungsweg zu
erkennen oder zu verfolgen.

| Systematik unterstützt die Vermeidung von Redundanz.

Eine gute Struktur ist bis zu einem
gewissen Grad selbsterklärend.

| Es ist einfacher zu überblicken, was man hat und was nicht <s>!

Problemspezifische Klassen

|
| Der Traum eines jeden OOP Freaks ist eine Applikation, die nur aus abgeleiteten Objekten besteht.
| Dies ist ein durchaus anstrebenswertes Ziel, welches man aber wohl nie erreichen wird.

Jede Applikation hat spezifische Probleme
die nur auf diese Applikation zutreffen, die zwar technisch als Klassen abgebildet werden, welche aber keinen großen Verallgemeinerungsgrad haben.

Aspekte einer Applikation,
die in ein Framework integriert sein können

| |
| Archivierung
| Stichwort:  DATA-Warehouse
| Backup und Restore
| Methoden für das tägliche Backup

Methoden für die Rücksicherung im
Notfall

| Geschäftsregeln

Methoden zur regelbasierten Datenbearbeitung,
wobei die Regeln in einer Tabelle hinterlegt sind
und jederzeit erweitert und geändert werden können

| Klassenbibliotheken

Allgemeine Elemente einer Applikation (I)

| |
| Kommunikation
| Methoden für die Kommunikation
| Internet Service/Zugriff
| Konfiguration
| Datenkonvertierung
| Verschlüsselung
| Applikations-Installation
| Fehlerbehandlung
| Masken

Allgemeine Elemente einer Applikation (II)

|
| Hilfe-System
| Internet-Zugriffsroutinen
| Adressaufkleber
| Serienbrief

Programm-Verwaltungsroutinen
für den Programmierer

Programmverwaltung für den
Anwender

| Menüs

Allgemeine Elemente einer Applikation (III)

|
| Multimedia-Methoden
| Multi-User-Verwaltung
| ActiveX-Komponenten
| ODBC-Zugriffe
| OLE-Automation
| OLE/DDE
| periphere Eingabe über Bar-Code-Leser
| Drucker- Management

Allgemeine Elemente einer Applikation (IV)

|
| Programm-Dokumentation
| Projekt-Management
| Abfragen
| Report-Management
| Reports
| Sicherheit
| System-Routinen
| System-Parameter / -Einstellungen
| Tabellen

Allgemeine Elemente einer Applikation (V)

|
| Benutzer-Dokumentation
| Benutzer-Unterstützung
| Benutzer-Training

Relation zwischen Applikation und Framework

| |
| eine Applikation....
| ...hat viele Objekte die aus Klassen erstellt werden
| ...hat Datenbanken,Tabellen und Relationen zwischen den Tabellen
| ...hat eine Benutzer-Schnittstelle
| ...hat eine Anzahl Standardfunktionen
| ...ist programmiert als eine Menge von Modulen

Relation zwischen
Applikation und Framework (I)

| |
| ein Framework...
| ...hat eine Klassenhierarchie, die die Klassen organisiert, aus der die Applikation besteht
| ...bietet Strukturen, die als Richtlinien dienen, wie die Daten in den Klassen und Elementen integriert werden
| ...hat viele visuelle Klassen zur optimalen Erstellung der Benutzer-Schnittstelle
| ...hat eine große Anzahl wiederverwendbarer Komponenten und unterstützt die Integration in die Applikation

Relation zwischen
Applikation und Framework (II)

|
| Der Entwurf einer Applikation ist nicht das selbe wie der Entwurf eines Frameworks, aber es ist das Ziel des Frameworks, die Applikationsentwicklung so weit wie möglich zu unterstützen.

Allgemeine Struktur
einer Applikation
(siehe auch Anhang VIIa!)

Allgemeine Struktur
einer Applikation (I)

| |
| Initialisierungs-Programm
| Jede Applikation muß irgendwie starten.
| Procedure File
| Meist nicht mehr ganz zeitgemäß <s>, aber hiermit sollen alle Prozeduren gemeint sein, die nicht in Klassen verpackt werden können.
| Main Menu
| das Hauptmenu der Applikation.
| Include Files
| alle Präprozessor Dateien

Allgemeine Struktur
einer Applikation (II)

| |
| Datenbank
| Abfragen
| Datenabfragen und Auswertungen
| Menüs und Toolbars

Jede Form sollte ihr eigenes Menü haben
und wenn sinnvoll, auch eine Toolbar.

| Forms und Formsätze
| bilden die eigentliche Benutzer-Schnittstelle
| Applikations-Dialogboxen

Jede Applikation hat solche Boxen in großer Zahl für die
verschiedenen Meldungen und Benutzer-Interaktionen

Allgemeine Struktur
einer Applikation (III)

| |
| Reports und Labels
| Es gibt wenige Applikationen ohne diese Bestandteile.
| Unterstützende Komponenten

Alle Arten von Komponenten und Modulenn
die den Applikations-Zweck und/oder die Existenz der Applikation unterstützen.

Wie das Framework die Struktur unterstützt
(siehe auch Anhang VIIa!)

Wie das Framework die Struktur unterstützt (I)

| |
| Standard Files

Es gibt ein Hauptprogramm, das man sich ins Projekt kopiert und im allgemeinen ein wenig anpassen muß.
Das gleiche gilt für die Include-Dateien.

| Menü-Vorlagen
| Es gibt meistens 2-3 Standardvorlagen, die ins Projekt kopiert werden müssen. Diese Menüs haben dann Standard-Optionen (siehe auch Microsoft Richtlinien).
| Toolbars sind nicht standardisiert und gehören meistens zu einem Formset.

Wie das Framework die Struktur unterstützt (II)

| |
| Datenelemente
| Die meisten Datenelemente sind applikationsspezifisch, mit Ausnahme derjenigen, die sich auf die unterstützenden Komponenten beziehen oder mit diesen zusammenarbeiten.
| Abfragen
| Abfragen sind meistens ganz problemspezifisch und müssen deshalb auch immer problembezogen neu erstellt werden.
| Problemspezifische Elemente
| Das sind meistens Reports und Labels. Die meisten können nur innerhalb einer bestimmten Applikation sinnvoll eingesetzt werden.

Wie das Framework die Struktur unterstützt (III)

| |
| Klassenhierarchie
| Die Struktur dieser Hirarchie ist die Mutter des Frameworks. Mit den Klassen werden die unterstützenden Komponenten und Module erzeugt.
| Problemspezifische Klassen
| Sie sind abgeleitet aus der Klassenhierarchie und dem Problem angepasst. Wenn möglich, dann sollte das Framework Forms und Formsätze enthalten, die zumindest innerhalb derselben Applikation mehrmals verwendbar sind.

Arten von Frameworks

|
| integrierte Frameworks
| komponenten-basierte Frameworks

Integrierte Frameworks

| |
| Vorteile:
| Integrierte Frameworks bieten einen sehr effektiv aufeinander abgestimmten Rahmen für viele Standardfälle.
| Nachteile:
| Die enge Verzahnung der einzelnen Bestandteile erschwert allerdings grundlegende technologische Anpassungen, wenn diese im Design des Frameworks nicht vorgesehen sind
| Beispiele aus dem deutschsprachigen Raum: VFX und CLASSMAXX

Komponenten-basierte Frameworks

| |
| Vorteile:
| Komponenten-basierte Frameworks beruhen auf einer relativ großen Menge unabhängiger Komponten, die man vielfältig erweitern und miteinander kombinieren kann.
| Nachteile:
| Die unabhängig programmierten Komponenten beinhalten einen gewissen Performance-Overhead, der durch etwas leistungsfähigere Technik ausgeglichen werden muß.
| Beispiel aus dem deutsch-sprachigen Raum: THE LIB (bzw. ACODEY)

Wie das Framework die Struktur unterstützt

| |
| Standard-Komponenten und -Module
| Es gibt eine sehr lange Liste von Modulen und Komponenten, die in vielen Applikationen immer wieder gebraucht werden
|
| Man kann festhalten:
| Je mehr wiederverwendbare Komponenten man einsetzt und je mehr man den OOP- Ansatz nutzt, um so wartungsfreundlicher und fehlerfreier werden die damit erstellten  Applikationen.

Folientitel

Hauptteiltext

Zweite Ebene

Dritte Ebene

Vierte Ebene

Fünfte Ebene

‹Nr.›

Unser Know-how für Ihre Projekte!

Click to edit Master title style

‹Nr.›

Unser Know-how für Ihre Projekte!

7. Visual FoxPro Entwicklerkonferenz 2000

Pre-Conference-Seminar

Frameworks in der VFP-Programmierung

© 2000 Sebastian Flucke

VII - ‹Nr.›