Dokumentation der Entwicklung und des Konzepts eines Frameworks

Hoffmann, Martin

Dokumentation der Entwicklung und des Konzepts eines Frameworks

Zusammenfassung

Inhaltsangabe:Zusammenfassung:
Diese Diplomarbeit beschreibt die Entwicklung des Konzepts des in der Firma ITData Consult GmbH entwickelten Frameworks und außerdem dessen Dokumentation. Zu Beginn beschäftigt sich die Arbeit mit den theoretischen Grundlagen der Wiederverwendung von Softwarekomponenten. Danach wird ein Überblick über die verschieden Dokumentationsformen gegeben. Der zweite Teil der Arbeit erläutert die Konzepte des erstellten Frameworks und geht auch auf in der Informatik gebräuchliche Konzepte wie z. B. die Bakus-Nauer-Form ein. Im dritten Teil wird schließlich die für die Dokumentation entworfene Dokumentations-form erläutert und somit die Teile eins und zwei verbunden.
Diese Arbeit entstand im Rahmen der Entwicklung des ITData Frameworks in enger Zusammenarbeit mit der Firma ITData Consult GmbH in Münster. Daher wird die Firma im Folgenden kurz vorgestellt.
ITData Consult wurde Anfang 2000 als GmbH gegründet. Diese gliederte sich bis Ende 2002 in die drei Geschäftsbereiche: Netzwerktechnik, Schulungen und Softwareentwicklung. Die Philosophie des Unternehmens bestand darin, dem Kunden einen umfassenden Service zu bieten, d.h. eine Firma kümmert sich um alle Wünsche des Kunden im EDV-Bereich. Da Hard- und Softwareprobleme oft Interdependenzen aufweisen, konnte ITData Consult durch die bisher gesammelten Erfahrungen auf ein großes Wissenspotential zurückgreifen und so einen, im Interesse des Kunden liegenden, optimalen und effizienten Lösungsweg erarbeiten.
Durch den Ausstieg einer der Gesellschafter Ende 2001 geriet das ganze Konzept ins Wanken, so dass ITData Consult Ende 2002 gezwungen war sich aus dem Bereich der Netzwerktechnik zurückzuziehen und sich auf die Kernkompetenzen der restlichen Mitarbeiter, die Softwareentwicklung, zu besinnen.
Um sich am Markt zu behaupten, wurde schon Mitte 2002 damit begonnen, den ITData Framework zu entwickeln, der im Zuge dieser Arbeit dokumentiert wird.
Mit dem Framework sollten alle Erfahrungen im Bereich der Softwareentwicklung in einer effizienten und wiederverwendbaren Umgebung verschmolzen werden. Diese sollte in Zukunft eine schnelle und reibungslose Softwareentwicklung garantieren und lange, teure Entwicklungszeiten verkürzen.
Leider musste ITData Consult Ende März 2003 kurz nach der Fertigstellung des Frameworks Insolvenz anmelden.
Trotz der Insolvenz der ITData Consult GmbH war die Entwicklung des Frameworks nicht umsonst, da die Rechte für den Framework auch weiterhin bei dem […]

Leseprobe

Inhaltsverzeichnis

ID 7709

Hoffmann, Martin: Dokumentation der Entwicklung und des Konzepts eines Frameworks

Hamburg: Diplomica GmbH, 2004

Zugl.: Fachhochschule Dortmund, Fachhochschule, Diplomarbeit, 2003

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2004

Printed in Germany

Vorwort

Diese Arbeit entstand im Rahmen der Entwicklung des ITData Frameworks in enger Zu-

sammenarbeit mit der Firma ITData Consult GmbH in Münster. Daher wird die Firma im

Folgenden kurz vorgestellt.

ITData Consult wurde Anfang 2000 als GmbH gegründet. Diese gliederte sich bis Ende

2002 in die drei Geschäftsbereiche: Netzwerktechnik, Schulungen und Softwareentwick-

lung. Die Philosophie des Unternehmens bestand darin, dem Kunden einen umfassenden

Service zu bieten, d.h. eine Firma kümmert sich um alle Wünsche des Kunden im EDV-

Bereich. Da Hard- und Softwareprobleme oft Interdependenzen aufweisen, konnte ITData

Consult durch die bisher gesammelten Erfahrungen auf ein großes Wissenspotential zu-

rückgreifen und so einen, im Interesse des Kunden liegenden, optimalen und effizienten

Lösungsweg erarbeiten.

Durch den Ausstieg einer der Gesellschafter Ende 2001 geriet das ganze Konzept ins

Wanken, so dass ITData Consult Ende 2002 gezwungen war sich aus dem Bereich der

Netzwerktechnik zurückzuziehen und sich auf die Kernkompetenzen der restlichen Mitar-

beiter, die Softwareentwicklung, zu besinnen.

Um sich am Markt zu behaupten, wurde schon Mitte 2002 damit begonnen, den ITData

Framework zu entwickeln, der im Zuge dieser Arbeit dokumentiert wird.

Mit dem Framework sollten alle Erfahrungen im Bereich der Softwareentwicklung in einer

effizienten und wiederverwendbaren Umgebung verschmolzen werden. Diese sollte in Zu-

kunft eine schnelle und reibungslose Softwareentwicklung garantieren und lange, teure

Entwicklungszeiten verkürzen.

Leider musste ITData Consult Ende März 2003 kurz nach der Fertigstellung des Frame-

works Insolvenz anmelden.

TEIL A: Wiederverwendung und Dokumentation - Grundlagen . 4

1. Motivation...4

2. Wiederverwendung ...4

2.1. Definition, Zielsetzungen und Gefahren...4

2.2. Stufen der Wiederverwendung...6

3. Ideen objektorientierter Wiederverwendung...8

3.1 Klassenbibliotheken...9

3.2 Design Patterns ...9

3.3 Application Frameworks...11

4. Dokumentation ...13

4.1. Definition der verwendeten Begriffe ...13

4.2. Ist-Zustand der Dokumentation in der betrieblichen Praxis...14

4.3. Voraussetzungen zur Förderung der Dokumentation ...15

4.4. Drei Teile der Dokumentation...16

4.5. Anforderungen an die Dokumentation...17

4.6. Dokumentationszeitpunkt und -techniken ...20

4.7. Schlussfolgerungen ...22

TEIL B: Konzeption des ITData Frameworks... 24

1. Motivation...24

2. Definition der Framework-Begriffe...24

3. Eigenschaften des Frameworks ...25

4. Dateiaufbau des Frameworks ...27

5. Module und Plugins ...28

6. Kommandos innerhalb des Frameworks ...32

6.1. Aufbau der Kommandos ...32

6.2. Allgemeines zur Backus-Nauer-Form...33

6.3. Funktionsweise der BNF des Parsers am Beispiel ...34

6.4. Die verwendbaren Kommandos ...37

7. Die Interfaces...38

7.1. ILibrary ...39

7.2. IScreen ...40

8. Initialisierung des Frameworks ...40

9. Die Navigation zwischen den Seiten ...42

9.1. Die Vorwärtsnavigation ...42

9.2. Die Rückwärtsnavigation...46

10. Fehlerbehandlung ...47

11. Terminierung des Frameworks ...49

TEIL C: Dokumentation des ITData Frameworks... 50

1. Motivation für die Dokumentation des ITData Frameworks ...50

2. Zur Dokumentation verwendete Hilfsmittel...50

2.1. Microsoft Excel ...50

2.2. ITData Catalog Publisher ...53

3. Anlegen der Baumstruktur für die Entwicklerdokumentation ...53

4. Schlussbemerkungen...56

Anhang... 57

1. Entwicklerdokumentation zum ITData Framework...57

2. Literaturverzeichnis...58

3. Abbildungsverzeichnis...60

TEIL A: Wiederverwendung und Dokumentation - Grundlagen

1. Motivation

Dieser Teilbereich soll einen Überblick über die beiden Gebiete Wiederverwendung und

Dokumentation liefern. Es werden Definitionen zu den verwendeten Begriffen gegeben

und die mit beiden Teilbereichen verfolgten Ziele beschrieben. Des Weiteren werden die

einzelnen Stufen der Wiederverwendung erläutert und kritisch bewertet, ebenso wie die

vorhandenen Techniken zur Dokumentation. Das Ziel dieses Teils der Arbeit ist, die Ent-

wicklung des ITData Frameworks in eine Stufe der Wiederverwendung einzuordnen und

ein geeignetes Konzept für die Dokumentation des Frameworks zu entwickeln.

2. Wiederverwendung

Dieser Teil beschäftigt sich mit dem Konzept der Wiederverwendung. Es wird auf die

Zielsetzungen und die Gefahren von Wiederverwendung eingegangen und eine Untertei-

lung in Stufen, die den Grad der Wiederverwendung, der in einem Unternehmen praktiziert

wird, beschreibt.

2.1. Definition, Zielsetzungen und Gefahren

Definition:

Wiederverwendung ist die Nutzung bereits bestehender Softwarekomponenten und kon-

zeptioneller Ideen in einem neuen Softwareprojekt.

Nach der Definition ist die Wiederverwendung als Recycling von bewährten Konzepten

und Teilen bereits entwickelter Software zu verstehen. Ein Beispiel für den typischen Fall

in dem die Wiederverwendung vorkommt, wäre z.B.: Ein Unternehmen hat in seinem letz-

ten Softwareprojekt eine Adressenverwaltung programmiert. Nun entsteht ein neues Pro-

jekt, das ebenfalls eine Adressenverwaltung enthalten soll. Dem Unternehmen stellen sich

nun zwei Möglichkeiten: Entweder es wird eine neue Adressenverwaltung programmiert

oder die Adressenverwaltung aus dem vorherigen Projekt wird an die neue Problemstel-

lung angepasst und in das neue Projekt übernommen. Entscheidet sich das Unternehmen

für die Übernahme der Komponente aus dem vorherigen Projekt, hat es sich damit auch für

eine Form der Wiederverwendung entschieden.

Im Zusammenhang mit der Wiederverwendung stellt sich die Frage, welche Zielsetzungen

das Unternehmen verfolgt, wenn es dem Konzept der Wiederverwendung nachgeht und

welche Vorteile sich daraus ergeben.

Oberstes Ziel eines Unternehmens, das an der freien Marktwirtschaft teilnimmt, ist die

Gewinnmaximierung. Um dieses Ziel zu verfolgen, müssen die Produkte des Unterneh-

mens am Softwaremarkt konkurrenzfähig sein, d.h. sie müssen einen guten Preis bei mög-

lichst geringen Entwicklungskosten erzielen. Da sich der Preis des Produktes nicht beliebig

weit nach oben treiben lässt, liegt eine weitere Möglichkeit der Gewinnmaximierung in der

Reduktion der Entwicklungskosten für das Produkt; im Fall eines Softwareentwicklers ist

dieses Produkt seine Anwendung. Um die Entwicklungskosten zu reduzieren ist es nötig,

die Entwicklungszeit für die Anwendung zu reduzieren, d.h. das Softwareprojekt muss

schneller abgewickelt werden. Bei dieser Reduktion kann das Wiederverwendungskonzept

hilfreich sein. Durch die Wiederverwendung bereits existenter Lösungen lassen sich so-

wohl die Entwicklungszeit, als auch die Testzeit für die Anwendung reduzieren, da viele

bereits vollständig ausgereifte Komponenten genutzt werden können

. Da sich die so recy-

celten Komponenten oft schon in der Praxis bewährt haben, sind die Testzeiten verhält-

nismäßig gering festzusetzen. Für die Konzeption einer Komponente sollte daher aus-

schlaggebend sein, wie leicht sie sich in anderen Applikationen wieder verwenden lässt

oder sich auch Teilkomponenten wiederverwerten lassen. Daher sollte darauf geachtet

werden, dass die Komponente einfache Schnittstellen bekommt, deren Verwendung mög-

lichst selbsterklärend oder zumindest leicht verständlich dokumentiert ist, damit die Zeiter-

sparnis durch Wiederverwendung nicht durch eine zu hohe Einarbeitungszeit wieder verlo-

ren geht.

Durch die Zeiteinsparungen kann des Weiteren eine effektivere Auslastung des Personals

gewährleistet werden, da sich durch die Nutzung der Wiederverwendung die Art der Pro-

grammierung verändert, d.h. die Aufgabe der Programmierer besteht dann zu einem großen

Teil darin, die Softwaresysteme aus bereits bestehenden Komponenten zusammenzusetzen.

Diese werden noch ggf. an die speziellen Anforderungen des Softwareprojektes angepasst.

So müssen in Zukunft nur noch Lösungen für neue Problemstellungen oder ergänzende

Teile, die Verbindungen zwischen den alten und den neuen Komponenten herstellen, pro-

grammiert werden

Vgl. Ruske, N.: S. 23

Vgl. Ruske, N.: S. 24

Ein weiterer Vorteil, der sich daraus ergibt, ist eine verbesserte Qualität der Anwendungen,

da die verwendeten Komponenten bereits zuvor vollständig getestet wurden und schon in

laufenden Systemen mit ihnen Erfahrungen gesammelt werden konnten, die auch zur Wei-

terentwicklung und Fehlerminimierung genutzt werden konnten.

Weiterhin ergibt sich eine einfachere Wartbarkeit, da die entwickelte und mehrfach einge-

setzte Komponente bei einem Fehler nur einmal geändert werden muss. Ebenso ist eine

einfachere Erweiterbarkeit der Anwendungen möglich.

Denkbar ist auch die Verwendung von Komponenten eines Fremdanbieters. Dabei ist zu

beachten, dass die Kosten der Komponente nicht die Kosten für eine Eigenentwicklung

übersteigen sollten. Außerdem ist wichtig, dass für die Suche der Komponente nicht mehr

Zeit verwendet wird, als für die Neuprogrammierung. Gerade auch, wenn im Internet nach

geeigneten Komponenten gesucht wird, sollte man darauf achteten, dass auch rechtzeitig

darüber nachgedacht wird, ob es nicht sinnvoll wäre, die Suche einzustellen und doch

selbst mit der Entwicklung der benötigten Komponente zu beginnen. Denn oft ist es

schwierig, wenn schon viel Zeit für die Suche aufgewendet wurde, rechtzeitig die Suche zu

beenden und sich mit diesem Misserfolg abzufinden.

Bei der Nutzung des Konzeptes der Wiederverwendung ist eine gute Dokumentation unab-

dingbar, denn zu hohe Einarbeitungszeiten in die Nutzung der vorhandenen Komponenten

kann das gesamte Konzept und die damit einhergehende Zeitersparnis zunichte machen.

2.2. Stufen der Wiederverwendung

In einigen Veröffentlichungen findet sich eine Einteilung in Stufen der Wiederverwendung

und inwieweit sich Unternehmen in diese Stufen einordnen lassen. Als Vorlage für diese

Arbeit dient die Stufeneinteilung von Ruske, N. (s. Literaturverzeichnis). Dort wird eine

Aufteilung in fünf Stufen propagiert, von denen allerdings nur die ersten drei Stufen sinn-

voll erscheinen.

1. Stufe: Ad-hoc-Wiederverwendung

Bei dieser Art der Wiederverwendung ist der Nutzen eher kurzfristig, denn sie besteht dar-

in, dass Codeteile kopiert werden und in einer anderen Komponente eingefügt und ange-

passt werden. Der Vorteil bei dieser einfachsten Art der Wiederverwendung ist die Ar-

beitsersparnis, da keine neue Lösung für ein bestehendes Problem erarbeitet werden muss.

Der Nachteil hierbei ist, dass die Wartung und die Fehlerbeseitigung für die jeweiligen

Codeteile geschehen muss. Somit kann es auch wieder zu inkompatiblen Versionen der

Codeteile und damit zu verschiedenen Evolutionsstufen einer Komponente in verschiede-

nen Anwendungen kommen.

2. Stufe: Wiederverwendung verfügbarer Komponenten

Diese Art der Wiederverwendung setzt eine Dokumentation der bekannten internen und

externen Software und Komponenten voraus. Um die Lauffähigkeit externer hinzugekauf-

ter Komponenten zu sichern, werden die eigenen Komponenten nach marktüblichen Stan-

dards entwickelt. Allerdings ist diese Stufe eher eine sporadische Wiederverwendung, denn

es findet keine explizite oder auch gezielte Entwicklung für die Wiederverwendung statt.

Der Nachteil hierbei liegt darin, dass das vorhandene Potential (vorhandene Komponenten)

nicht ausgenutzt wird.

3. Stufe: Entwicklung für die Wiederverwendung

Durch die Förderung der Wiederverwendung durch das Management eines Unternehmens

werden geeignete Infrastrukturen geschaffen. Softwarekomponenten werden nicht für ein

einziges Softwareprojekt erstellt, sondern als Module verstanden, die je nach den Anforde-

rungen des Softwareprojektes zusammengestellt werden. So kann es z.B. eine Mail-, eine

Adressen-, eine Buchhaltungs-, eine Termin- und eine Reservierungskomponente geben,

die in unterschiedlichen Anwendungen genutzt werden oder zu unterschiedlichen Anwen-

dungen zusammengesetzt werden. Änderungen oder Anpassungen einer Komponente kön-

nen somit den verschiedenen Anwendungen zu gute kommen. Somit kommt es nicht zu

verschiedenen Evolutionsstufen der einzelnen Komponenten in den unterschiedlichen An-

wendungen.

Es wird eine einheitliche Form der Dokumentation von Komponenten geschaffen und auch

die Entwicklung von wiederverwendbaren Klassenbibliotheken wird gefördert.

Des Weiteren sind verschiedene Richtlinien und Vorgehensweisen zu definieren, um eine

einheitliche Entwicklung der Komponenten zu gewährleisten. Ein Beispiel sind Program-

mierrichtlinien (Konventionen), die die Lesbarkeit des Programmcodes erleichtern.

Weiteres Ziel kann die Schaffung eines Frameworks sein, dass als Rahmenprogramm für

die aus den einzelnen Komponenten gezielt neu zusammengesetzten Anwendungen dienen

kann.

Daraus leitet sich ein Bewusstsein über die Vorteile der Wiederverwendung (kürzere Ent-

wicklungszeiten, höherer Profit) ab.

Die in Ruske, N. beschriebene Stufe vier (Verwendung von Domänenmodellen und statis-

tische Steuerung des Prozesses) geht in dieser Arbeit bereits in den Stufen zwei und drei

auf. Es wird bewusst darauf verzichtet, eine weitere Stufe (Stufe fünf) für die ,,Organisati-

onsweite Ausrichtung auf Wiederverwendung" einzuführen. Die Wiederverwendung auf

alle anderen Abteilungen auszuweiten erscheint nicht besonders erfolgversprechend, da

z.B. Kunden immer noch eine individuelle Beratung wünschen und man nicht immer nur

auf bereits bestehende Muster zurückgreifen kann, um die Kunden zufriedenzustellen. Dies

würde auch die Kreativität und den technischen Fortschritt einengen, da kein Platz mehr

für individuelle Lösungen bleibt. Auf lange Sicht bedeutet eine hundertprozentige Wieder-

verwendung in allen Unternehmensbereichen einen Stillstand der Entwicklungen. Es be-

steht dann die Gefahr, dass das Unternehmen von den Mitbewerbern im Marktsegment

überholt wird.

Zusammenfassend lässt sich sagen, dass das Konzept der Wiederverwendung den Unter-

nehmen eine große Chance bietet, durch effizientere Nutzung der Ressourcen eine schnel-

lere Entwicklung von Anwendungen und somit einen höheren Profit zu realisieren. Um

aber um einen hohen Grad an Wiederverwendung zu gewährleisten, ist es unabdingbar,

eine genaue Dokumentation der einzelnen Komponenten vorzunehmen. Eine organisati-

onsweite Ausrichtung ist vom Konzept her lobenswert, kann aber bei fehlender Reaktions-

fähigkeit des Managements auch auf das Abstellgleis führen, wenn das Management unter

Umständen zu spät erkennt, dass Forschung und Entwicklung zu kurz gekommen sind.

3. Ideen objektorientierter Wiederverwendung

Das Konzept der Wiederverwendung wird auch durch die Etablierung der objektorientier-

ten Sprachen sehr gefördert, da gerade objektorientierte Sprachen durch die Nutzung des

Klassen- und Vererbungskonzeptes die Wiederverwendung und die Anpassung zur Wie-

derverwendung sehr erleichtern.

Die wichtigsten Ideen bei objektorientierter Wiederverwendung sind Klassenbibliotheken,

Design Patterns und Application Frameworks. Im Folgenden werden diese drei Konzepte

kurz vorgestellt.

3.1 Klassenbibliotheken

Eine Klassenbibliothek ist eine Sammlung von Klassen, die in der gleichen objektorientier-

ten Programmiersprache entwickelt wurden und nach bestimmten Kriterien, wie z.B. dem

Anwendungsgebiet, in eben dieser Klassenbibliothek gebündelt werden.

Die Klassenbib-

liothek wird bei Bedarf einem Projekt hinzugefügt und die einzelnen Klassen können dann

für die für sie vorgesehenen Aufgaben eingesetzt werden. Innerhalb einer Klassenbiblio-

thek können Vererbungshierarchien aufgebaut werden, um so auch schon innerhalb der

Klasse das Konzept der Wiederverwendung zu nutzen

. Auch die Klassenbibliotheken

müssen über eine hinreichend gute Dokumentation verfügen, damit ihr Sinn und Zweck

relativ schnell deutlich wird und sich somit die Entwicklung von neuen Anwendungen in

einem möglichst kurzen Zeitraum realisieren lässt.

3.2 Design Patterns

Design Patterns (Entwurfsmuster) bezeichnen nicht die Wiederverwendung von Pro-

grammcode, sondern die Wiederverwendung von Konzepten, die während der Entwurfs-

phasen verschiedener Projekte entstanden sind. Die Lösungen werden relativ abstrakt

gehalten und müssen dann an das jeweilige Problem spezifisch angepasst werden. Man

kann Design Patterns auch als Lösungsvorschlag verstehen, mit dem man unter Umständen

schneller zur Lösung der eigenen Problemstellung gelangt.

Ein Design Pattern sollte folgendermaßen aufgebaut sein

· Bezeichnung

Die Bezeichnung sollte selbsterklärend und eindeutig sein und die Problemstellung

charakterisieren.

· Problemstellung

Hier wird das Problem beschrieben und erläutert. Außerdem sollte erklärt werden,

in welchem Kontext das Problem zu sehen ist, damit der potentielle Nutzer schnell

entscheiden kann, ob diese Problemstellung seiner ähnelt oder sogar entspricht.

· Beschreibung der Problemlösung

Vgl. Balzert, Heide: S. 283

Vgl. Ruske, N.: S. 65

Vgl. Balzert, Heide: S. 282, Ruske, N.: S. 67

Durch diese Beschreibung muss die Lösung des Problems ersichtlich werden. Sie

ist im übertragenen Sinne eine Bauanleitung für eine Struktur, die dieses Problem

löst.

· Beschreibung der Konsequenzen

Aus der Beschreibung der Konsequenzen, soweit sie ersichtlich sind oder soweit sie

bekannt sind, muss hervorgehen, welche Risiken die Lösung mit sich bringt. Der

Nutzer muss anhand dieser Beschreibung entscheiden können, ob der Nutzen das

Risiko oder auch die etwaigen Einschränkungen übersteigt und somit die Verwen-

dung des Design Patterns zu befürworten ist.

Abbildung 1: Ein Beispiel für ein Design-Pattern: Das Beobachter-Muster

Bezeichnung:

Beobachter-Muster

Problemstellung:

Bei der Änderung eines Objektes sollen alle von diesem Objekt abhängigen Objekte

automatisch benachrichtigt und aktualisiert werden.

Dabei ist von folgendem Kontext auszugehen, dass eine Abstraktion zwei oder mehr As-

pekte besitzt, die in einer wechselseitigen Beziehung stehen. Dabei ist durch die Kapselung

in zwei oder mehr Objekte die Möglichkeit der Wiederverwendung und Modifikation ge-

geben.

Vgl. Balzert, Heide: S. 296

Eine weitere Verwendungsmöglichkeit wäre, wenn nicht bekannt ist, wie viele Objekte bei

der Änderung eines Objektes ebenfalls geändert werden müssen oder wenn ein Objekt nur

lose an andere Objekte gekoppelt ist und diese benachrichtigt werden sollen.

Beispiel: Ein Objekt enthält Anwendungsdaten und diese Daten sollen in unterschiedlichen

Formen dargestellt werden (Tabelle und Diagramm). Dabei stehen die beiden Anzeigeob-

jekte (Beobachter) in keiner Beziehung zueinander. Das Anwendungsobjekt (Subjekt)

kennt seine Anzeigeobjekte und informiert sie auf deren Anfragen hin über alle Änderun-

gen. Die Beobachter synchronisieren sich den gemeldeten Änderungen entsprechend.

Beschreibung der Problemlösung:

Die Subject-Klasse kennt beliebig viele Observer (Beobachter). Eine Schnittstelle wird

durch die Observer-Klasse definiert, die die Concrete-Observer-Klasse benötigt, um über

die Änderungen eines Subjetcs informiert zu werden. Die Objekte der Concrete-Subject-

Klasse speichern die Daten, die für die Concrete-Observer von Interesse sind. Der Concre-

te-Observer merkt sich den Zustand des Concrete-Subjects und sichert auch die Konsistenz

dieser Daten. Dies wird durch die Implementierung des Interfaces gewährleistet.

Beschreibung der Konsequenzen:

Das Beobachtermuster ermöglicht es, Subjekte und Beobachter unabhängig voneinander zu

modifizieren. Die Beobachter und die Subjekte können einzeln wiederverwendet werden.

Neue Beobachter können ohne Änderung des Subjektes hinzugefügt werden.

3.3 Application Frameworks

Ein Framework bezeichnet sowohl die Wiederverwendung von Programmcode, als auch

von konzeptionellen Ideen und deren Lösungen. Ein Framework sollte so weit von einer

konkreten Problemstellung abstrahiert sein, dass er als Grundgerüst für jede neue Anwen-

dung dienen kann. Der Framework sollte als Rahmen für die in ihm erstellten Anwendun-

gen verstanden werden. Dieser Rahmen kann z.B. die Infrastruktur für die Kommunikation

der einzelnen Frameworkkomponenten, die Darstellung der Benutzeroberfläche, die Be-

handlung von Fehlern und weiteren wiederkehrenden Problemstellungen liefern.

Die Verwendung eines Frameworks geschieht in der Praxis im Moment noch nicht so häu-

fig

, da einem wirklich ausgereiften Framework eine lange Entwicklungsphase vorausgeht.

Vgl. Schmitzer, B.: S. 1

Diese Entwicklungszeit muss natürlich von einem Unternehmen vorfinanziert werden, da

mit dem Framework an sich nur selten direkt Geld verdient werden kann, sondern erst mit

den Anwendungen, die dann in dem Framework laufen. Die Investition lohnt sich aller-

dings, da entsprechende Framework-Anwendungen schneller entwickelt werden können

als traditionelle Anwendungen. Die Zeitersparnis verhilft dem Unternehmen zu einem

Vorsprung gegenüber seinen Marktkonkurrenten. Es kann nämlich mehr Aufträge inner-

halb kürzerer Zeit abwickeln und hat somit schnell sein investiertes Kapital wieder heraus.

Somit zahlt sich auch die Entwicklung des Frameworks auf lange Sicht aus.

Die Entwicklung eines Frameworks ist auf jeden Fall in die Stufe drei der Wiederverwen-

dung (Entwicklung für die Wiederverwendung) einzuordnen.

Framework

Einzelne Anwendung

im Framework

Abbildung 2: Grafische Darstellung eines Frameworks

4. Dokumentation

Dieser Abschnitt definiert die benötigten Begriffe im Zusammenhang mit dem Begriff der

Dokumentation. Außerdem wird der Ist-Zustand der Dokumentation in der Praxis geschil-

dert und Anregungen zur Förderung der Dokumentation gegeben. Dann wird eine Eintei-

lung der Dokumentation in drei verschiedene Teile vorgenommen und auf die Anforderun-

gen, die an eine Dokumentation gestellt werden, eingegangen. Weiterhin beschäftigt sich

dieser Teil mit den verschiedenen Zeitpunkten, an denen mit der Dokumentation begonnen

werden kann. Danach folgt ein kurzer Überblick über die Techniken, mit denen eine Do-

kumentation gestaltet werden kann.

Ziel dieses Abschnittes ist es, herauszufinden, wie eine Dokumentation für den ITData

Framework aufzubauen ist. Ein weiteres Ziel ist es, vorhandene Barrieren abzubauen, so

dass diese Arbeit als Beispiel einer Dokumentation dienen kann.

4.1. Definition der verwendeten Begriffe

Die Dokumentation wird sowohl in der Theorie als auch in der Praxis noch immer stief-

mütterlich behandelt. Es gibt mehr Autoren, die sagen, wie wichtig die Dokumentation ist,

als Autoren, die sich wirklich mit der konkreten Entwicklung einer Dokumentationsme-

thode beschäftigen oder sogar ein der betrieblichen Praxis entsprechendes Dokumentati-

onsbeispiel liefern. In der Praxis hingegen werden die Vorteile einer Dokumentation oft

noch immer nicht erkannt; dadurch wird auch die Entwicklung einer eigenen Dokumenta-

tionsmethode nicht gefördert.

Um wirklich eine entsprechende Dokumentationsmethode zu entwickeln, sollte zuerst eine

Übersicht über die gebräuchlichen Fachtermini geschaffen werden:

a) Dokumentation

Der Begriff Dokumentation steht sowohl für den Prozess, als auch das fertige Produkt

Das Produkt ist eine Sammlung von Informationen zu einem bestimmten Projekt, das

in gedruckter und / oder in elektronischer Form vorliegt.

Der Prozess der Dokumentation ist evolutionär und zeitlich nicht begrenzt, d.h. die

Dokumentation unterliegt einem ständigen Wandel und der Prozess ist nicht abge-

schlossen, solange an dem Projekt, sei es auch nur zu Wartungszwecken, noch gearbei-

tet wird.

Vgl. Lehner, F.: S. 3

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2003
ISBN (eBook): 9783832477097
ISBN (Paperback): 9783838677095
DOI: 10.3239/9783832477097
Dateigröße: 1 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Dortmund – Informatik
Erscheinungsdatum: 2004 (Februar)
Note: 1,7
Schlagworte: wiederverwendung entwicklerdokumentation module backus-nauer-form kommando

Autor

Martin Hoffmann (Autor:in)

Dokumentation der Entwicklung und des Konzepts eines Frameworks

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Martin Hoffmann (Autor:in)