Automatisierte Softwaregenerierung aus UML-Modellierungsinformationen

Inhaltsverzeichnis

Thesen

1. Einleitung
1.1. Motivation
1.2. Aufgabenstellung
1.3. Aufbau dieser Arbeit

2. Grundlagen
2.1. Voraussetzung zum Verständnis
2.2. Softwarequalität
2.3. Quantität
2.4. Wiederverwendung
2.5. Abstrakte grafische Beschreibungssprache
2.6. CASE-Tool
2.7. Softwaregeneratoren
2.8. Frameworks
2.9. Domain Engineering
2.10. Praxisbeispiel

3. Forschungsschwerpunkte
3.1. Object-Oriented Programming (OOP)
3.2. Subject-Oriented Programming (SOP)
3.3. Aspect-Oriented Programming (AOP)
3.4. Adaptive Programming (AP)/Demeter
3.5. Transformationssysteme
3.6. Parametrisierte Typen
3.7. GenVoca
3.8. Generative Programming
3.9. Intentional Programming (IP)
3.10. Generative Softwarekonstruktion
3.11. Softwaregenerator
3.12. Zusammenfassung

4. Umsetzung von UML in Code
4.1. Klassen, Attribute und Methoden
4.2. Vererbung und Schnittstellenimplementierung
4.3. Assoziation
4.3.1. Unidirektional
4.3.2. Bidirektional
4.4. Zusammenfassung

5. Architektur FlexiGen
5.1. Zweck
5.2. Typ
5.3. Motivation
5.4. Probleme
5.5. Lösungen
5.5.1. Lösung für inkompatible Quellen
5.5.2. Lösung für verschiedene Ausgaben
5.5.3. Lösung für Dynamik
5.5.4. Erweiterte Lösung für Dynamik
5.5.5. Lösung für Codegenerierung
5.6. Struktur
5.7. Teilnehmer
5.8. Interaktionen
5.9. Ablauf
5.10. Konsequenzen
5.11. Implementierung
5.11.1. Statischer Singleton
5.11.2. Manager
5.11.3. Adapter
5.11.4. Generator
5.12. Bekannte Verwendungen

6. Zusammenfassung
6.1. Spekulation über die zukünftige Entwicklung

A. Namenskonventionen

B. Glossar

Literaturverzeichnis

Erklärung

Thesen

1. Die Wiederverwendung ist ein wirksames Mittel zur Verbesserung der Qualität, zur Verkürzung der Entwicklungszeit und zur Senkung des Wartungsaufwandes bei der Entwicklung von Software.

2. Entwurfs- und Architekturmuster ermöglichen eine Wiederverwen- dung auf der Entwurfsebene und eine effizientere Kommunikation zwischen den Softwareentwicklern.

3. Der komplette Entwurf von Software wird zukünftig mittels abstrak- ter Beschreibungssprachen erfolgen. Damit wird ein plattform- und zielsprachenunabhängiges Design ermöglicht.

4. Zentrale Werkzeuge beim Softwareentwurf werden die CASE-Tools sein. Basierend auf einem Repository können sie verschiedene Schrit-te in der Softwaerentwicklung unterstützen und unterschiedliche Sich-ten konsistent darstellen. Das Ergebnis ist eine abstrakte Beschrei-bung.

5. Programmcode und Anwendungen können auf Grundlage der ab- strakten Modellbeschreibung mit Hilfe von Generatoren automatisch erstellt werden.

6. Bei der Entwicklung von Anwendungen wird man sich auf die Mo- dellierung der fachlichen Aspekte beschränken können. Für die tech-nischen Aspekte werden vorgefertigte Lösungen eingesetzt. Die An-bindung der Fachlogik an die technische Architektur erfolgt durch Generatoren.

7. Aus Punkt 6 folgt, dass Entwickler von technischen Lösungen ent- sprechende Generatoren bereitstellen müssen. Eine flexible Archi- tektur für solche Generatoren ist das im Rahmen dieser Arbeit ent- wickelte Frameworkdesign FlexiGen.

8. Durch die Verwendung von FlexiGen erreicht man Wiederverwen- dung auf Entwurfsebene. Die Architektur selbst ist eine Kombinati- on verschiedener Entwurfsmuster.

9. FlexiGen entkoppelt Generator und CASE-Tool in dem es Genera- tormodule und Adaptermodule definiert. Dadurch wird eine späte- re Erweiterung um neue Generatoren bzw. Anpassung für weitere CASE-Tools mit nur minimalem Aufwand ermöglicht.

Ilmenau, den 26. Juni 2000

Tobias Lindig

Abbildungsverzeichnis

2.1. Rolle der Softwaregeneratoren

2.2. Für Generierung geeignete Anwendungsarchitektur

2.3. Beispiel Domain Engineering

4.1. Klassendiagramm: einfache Klasse.

4.2. Klassendiagramm: Vererbung..

4.3. Klassendiagramm: Assoziation.

4.4. Klassendiagramm: Komposition

4.5. Klassendiagramm: bidirektionale Aggregation.

5.1. Kombination verschiedener Module über eine gemeinsame Schnittstelle..

5.2. Komponentendiagramm

5.3. Muster Adapter.

5.4. Muster Brücke..

5.5. Muster Singleton

5.6. Muster Abstrakte Fabrik

5.7. Muster Fabrikmethode.

5.8. Muster Schablonenmethode

5.9. Struktur.

5.10. Objektbaum eines einfachen C++-Headers

1. Einleitung

1.1. Motivation

Softwareprojekte werden immer größer und komplexer. Die Anforderungen an Qualität und Quantität nehmen ständig zu. Um im Wettbewerb bestehen zu können, wird intensiv nach Mitteln und Wegen gesucht, diesen Anforderungen gerecht zu werden. Ein großes Potenzial liegt in der Verbesserung des Entwurfsprozesses, der Wiederverwendung von Software und der Automatisierung der Applikationserstellung.

Bei der Entwicklung von neuer Software wird zunehmend versucht, solange wie möglich unabhängig von der späteren Implementierung zu bleiben. Dazu bedient man sich abstrakter Beschreibungsformen wie z.B. der UML¹. Auf Grundlage dieser abstrakten Modelle ist es möglich, Teile des Programmcodes automatisch zu erzeugen. Diese Entwicklung steht aber erst an ihrem Anfang.

In dieser Diplomarbeit wird auf die Vor- und Nachteile der Softwa-regenerierung eingegangen und ein Überblick über den aktuellen Stand der Entwicklung gegeben. Weiterhin wird eine Architektur für einen fle-xiblen Softwaregenerator vorgestellt. Auf Basis dieser Architektur kann z.B. ein Codegenerator erstellt werden, der auf Grundlage eines UML-Modells, welches mit einem CASE-Tool modelliert wurde, Programmcode erzeugt. Bei der Architektur wurde besonderer Wert auf Flexibilität und Erweiterbarkeit des Generators gelegt. So können z.B. verschiedene CASE-Tools unterstützt und verschiedene Arten von Code generiert werden.

1.2. Aufgabenstellung

Die Aufgabe besteht in der Entwicklung eines Musters für einen modular aufgebauten Softwaregenerator mit dem Ziel der automatisierten Erzeugung von Applikationen auf Grundlage der mit UML-basierten CASETools modellierten Informationen.

- Untersuchung vorhandener Ansätze und Lösungen zur generativen Programmierung
- Betrachtungen zur Realisierbarkeit automatischer Applikationsgenerierung, resultierende Einschränkungen und Abgrenzungen
- Architekturvorschlag; Verwendung von Architektur- bzw. Entwurfs-mustern
- Prototypische Beispielimplementation eines Generators mit Anbin-dung an führende kommerzielle CASE-Tools, wie Rational Rose, SE-LECT Enterprise und OTW. (Speziell zur Erzeugung aller von einer modellierten Applikation benötigten Codeteile für Datenbankzugrif-fe über das Produkt GRIT Connect der Firma GFT Systems GmbH )

1.3. Aufbau dieser Arbeit

Im Kapitel 2, Grundlagen, wird auf die Notwendigkeit der Wiederver-wendung von Software eingegangen, und es werden einige Begriffe und Techniken erklärt. Das Kapitel schließt mit einem Praxisbeispiel, bei wel-chem CASE-Tools, Frameworks und Codegeneratoren erfolgreich einge-setzt wurden.

Kapitel 3, Forschungsschwerpunkte, stellt eine Reihe von Forschungsprojekten und Produkten aus dem Umfeld der generativen und komponentenbasierten Softwareentwicklung vor.

Kapitel 4, Umsetzung von UML in Code, erläutert, wie die Umset-zung der Elemente eines UML-Klassendiagramms in C++-Programmcode erfolgen kann.

1.3. Aufbau dieser Arbeit

Das vom Autor dieser Diplomarbeit entwickelte Design eines Frame-works zur Softwaregenerierung wird im Kapitel 5, Architektur FlexiGen, vorgestellt. In den Abschnitten 5.1 und 5.2, Zweck bzw. Typ, wird knapp beschrieben, welche Möglichkeiten die Architektur bietet und um welche Art von Architektur es sich handelt. Abschnitt 5.3, Motivation, beschreibt ein Anwendungsproblem, für das auf Basis des Musters eine Lösung er-stellt wurde. Im Abschnitt 5.4, Probleme, werden die Probleme, bei de-nen das Muster angewandt werden kann, explizit aufgeführt und in 5.5, Lösungen, werden die im Muster verwendeten Problemlösungen und Va-riationsmöglichkeiten im Detail erläutert. Abschnitt 5.6, Struktur, enthält ein UML-Klassendiagramm, in welchem die Klassen des Musters mit ih-ren Beziehungen dargestellt sind. Abschnitt 5.7, Teilnehmer, beschreibt die Zuständigkeiten der am Muster beteiligten Klassen bzw. ihrer Ob-jekte. Die Zusammenarbeit der Objekte wird im Abschnitt 5.8, Interak-tionen, beschrieben und die Reihenfolge der Aktionen bei der Nutzung der Objekte im Abschnitt 5.9, Ablauf. Der Abschnitt 5.10, Konsequen-zen, diskutiert einige Vor- und Nachteile, die sich bei der Anwendung des Musters ergeben, und zeigt einige Variationsmöglichkeiten auf. Schließlich werden im Abschnitt 5.11, Implementierung, konkrete Hinweise für ei-ne Implementierung der Architektur gegeben und mit Beispielen in C++ veranschaulicht.

Im Kapitel 6, Zusammenfassung, sind eine Bewertung der vorliegenden Arbeit und eine Spekulation über die zukünftige Entwicklung der Softwareindustrie zu finden.

2. Grundlagen

Dieses Kapitel geht auf einige Probleme der Softwareentwicklung und War-tung ein. Dazu wird beschrieben, was unter Softwarequalität zu verstehen ist, und wie sie verbessert werden kann. Besonderes Augenmerk gilt dabei der Wiederverwendung von Software und einigen Techniken, die diese im besonderen Maße unterstützen. Das Kapitel schließt mit einem Beispiel aus der Praxis, bei welchem ein wesentlicher Grund für den Erfolg des Projektes der Einsatz von Frameworks und Codegeneratoren war.

2.1. Voraussetzung zum Verständnis

Die vorliegende Arbeit ist im Bereich der objektorientierten Softwareent-wicklung angesiedelt. Somit basiert sie auf den dort verwendeten Grund-begriffen und Annahmen. Das Verständnis von allgemeinen Begriffen wie Paket, Klasse, Aggregation, Generalisierung oder Delegation ist sehr dien-lich. Eine kurze Definition einiger Begriffe ist im Glossar zu finden. Für weiter gehende Information zu diesen Grundlagen ist in der entsprechen-den Fachliteratur aus dem Bereich der objektorientierten Softwaretechnik nachzulesen. Die Darstellung von Klassen und Strukturen erfolgt mit der UML. Darum ist es für das Verständnis der Arbeit erforderlich, mit die-ser Notation vertraut zu sein. Auch wird ein grundsätzliches Verständ-nis für das Prinzip von Entwurfsmustern vorausgesetzt. Bezüglich UML ist z.B. [Oes97] zu empfehlen, das Standardwerk für Entwurfsmuster ist [GHJV96].

2.2. Softwarequalität

In der DIN-Norm [DINb, 2.1] wird Qualität folgendermaßen definiert: ”QualitätistdieGesamtheitvonMerkmaleneinerBetrach- tungseinheit bezüglich ihrer Eignung, festgelegte und voraus gesetzte Erfordernisse zu erfüllen.“

Für Software sind in der DIN-Norm [DINa] folgende Qualitätsmerkmale definiert:

- Funktionalität

”[...]VorhandenseineinerMengevonFunktionen,diefestgelegte oder vorausgesetzte Erfordernisse erfüllen.“

- Zuverlässigkeit

”[...]FähigkeitderSoftware,ihrLeistungsniveauunterfestgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.“

- Benutzbarkeit

”[...]Aufwand,derzurBenutzungderSoftwareerforderlichist,so-wie die individuelle Bewertung einer solchen Benutzung durch eine festgelegte oder vorausgesetzte Gruppe von Benutzern.“

- Effizienz

”[...]VerhältniszwischendemLeistungsniveauderSoftwareunddem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.“

- Änderbarkeit

”[...]Aufwand,derzurDurchführungvorgegebenerÄnderungennot- wendig ist.“

- Übertragbarkeit

”[...]EignungderSoftware,voneinerUmgebungineineandere übertragen zu werden.“

2.2. Softwarequalität

Dabei zählen Funktionalität, Zuverlässigkeit, Benutzbarkeit und Effizienz zu den äußeren Qualitätsmerkmalen sowieÄnderbarkeit undÜbertragbarkeit zu den inneren Qualitätsmerkmalen.

Die Erfüllung der äußeren Qualitätsmerkmale ist anhand der in ei-nem Pflichtenheft definierten Anforderungen relativ leicht zu kontrollie-ren. Hingegen lassen sich die inneren Qualitätsmerkmale nur schwer bei der Abnahme der Software vom Auftraggeber überprüfen. Aber genau diese inneren Qualitätsmerkmale haben einen entscheidenden Einfluss auf die Kosten beim Einsatz der Software. Zahlreiche Studien kommen zu dem Ergebnis, dass der weitaus größte Teil der im Bereich der Softwa-re anfallenden Kosten zur Pflege und Wartung der Software aufgewendet wird [bs98][Mer00]. Unter Wartung und Pflege sind alle Maßnahmen zu verstehen, die nach dem Ende der Garantiezeit erfolgen. Hierzu gehören auch Tätigkeiten, die eine bestehende Anwendung verbessern, optimieren, reparieren oder überprüfen, mit dem Ziel, die Anwendung weiterhin bzw. besser nutzen zu können [Oes00, Glossar].

Mangelhafte Qualität der Software führt aber nicht erst beim Anwen-der zu höheren Kosten, sondern auch schon beim Entwickler. So stellen die Kosten für die Beseitigung von Produktmängeln in der Regel direkt entgangenen Gewinn dar. Der Zeitaufwand für die Beseitigung ist umso größer, je komplexer und unstrukturierter ein Programm ist. Somit sollte es im Interesse aller Beteiligten liegen, Software mit einer hohen Qualität zu erstellen. Leider ist es aber so, dass qualitativ hochwertige Software zwar in der Wartung günstiger ist, aber in der Erstellung einen gewissen Mehraufwand verlangt und somit schon am Anfang höhere Investitionen erfordert.

Eine vielversprechende effektive Möglichkeit, sowohl die Qualität der Software zu steigern, als auch die Kosten für deren Erstellung zu senken, ist durch den Einsatz von Softwarekomponenten bzw. von Softwaregenerie-rung gegeben. Anstelle der komplett neuen Programmierung einer eigenen Lösung setzt man so auf die Wiederverwendung von Software und kann somit auch von den Vorzügen der Wiederverwendung profitieren (siehe 2.4 Wiederverwendung).

2.3. Quantität

Die Anforderung an die Quantität äußert sich darin, dass immer größere Projekte in immer kürzerer Zeit zu realisieren sind. Dies wird darüber hin-aus durch die erhöhten Aufwendungen für die Wartung noch erschwert. Diese Aufwendungen steigen zurzeit proportional mit der Zahl der abgeschlossenen Projekte und führen zu einem so genannten ”Anwendungs- stau“ in den EDV-Abteilungen¹ der Unternehmen. Hierdurch werden dringend benötigte Kapazitäten gebunden und können deshalb nicht für Neuentwicklungen eingesetzt werden. [OSV99a]

Diese Problematik ist schon seit einiger Zeit bekannt und der Hintergrund zahlreicher Studien und Forschungsprojekte. Die Studien kommen zu einem weitestgehend einheitlichen Ergebnis, wie diesem Problem zu begegnen ist. Zum Beispiel heißt es in dem Bericht zum Forschungsprojekt OSVA [OSV99a, Gesamtziel des Vorhabens]:

”ErstensmüssenoffeneSoftwarearchitektureninFormvonAr-chitekturfamilien herausgearbeitet werden, die unbedingt auf der Wiederverwendung von Softwarekomponenten beruhen.“

”ZweitensmüssenkorrekteAnalyse-undEntwurfsmethoden zur Synthese und Verifikation solcher Softwarearchitekturen eingesetzt werden, die eine ingenieurmäßige Softwareentwicklung ermöglichen.“

Architekturfamilien lassen sich mit Hilfe des Domain Engineering finden (siehe 2.9 Domain Engineering). Das Domain Engineering versucht, eine Referenzarchitektur zu extrahieren. Eine solche Lösung bietet die Möglich-keit, schnell an veränderte Rahmenbedingungen angepasst zu werden und kann dadurch die Softwarewiederverwendung schon auf der Entwurfsebe-ne unterstützen. Eine solche Referenzarchitektur wurde im Rahmen dieser Diplomarbeit entwickelt und ist im Kapitel 5 beschrieben.

Somit ist die Wiederverwendung auch in Bezug auf die Quantität die zu favorisierende Lösung.

2.4. Wiederverwendung

Wie zuvor erwähnt, kann die Wiederverwendung von Software ein effek-tives Mittel zur Erhöhung der Qualität und zur Verkürzung der Entwick-lungszeit darstellen und somit zur Kostensenkung und Quantitätssteige-rung führen.

Was verbirgt sich hinter diesen Effekten und wodurch können sie erzielt werden? Einfach gesagt, durch die Wiederverwendung wird Redundanz vermieden, d.h. es wird versucht, das ”Rad“nichtnocheinweiteresMal zu erfinden. Zur Veranschaulichung folgendes Beispiel:

Es besteht die Aufgabe, drei verschiedene Haushaltsgeräte (z.B. ein Ra-dio, eine Waschmaschine und ein Lampe) zu einer vorgegebenen Zeit automatisch einzuschalten. Eine mögliche Lösung wäre es, in jedes spe-zielle Gerät eine eigene Uhr für die Zeitsteuerung einzubauen. Als al-ternative Möglichkeit könnte man aber auch nach einer allgemeinen Lösung suchen, das heißt nach einer, die für alle Haushaltsgeräte glei-chermaßen geeignet ist.

Alle Haushaltsgeräte werden über eine Steckdose mit Strom versorgt, haben somit eine kompatible Schnittstelle. Wenn man nun eine Zeitschaltung entwickelt, die zwischen Stecker und Steckdose einzusetzen ist, hätte man eine allgemeine Lösung für alle elektrischen Geräte. Vielleicht gibt es auch schon eine solche Komponente auf dem Markt. Diese könnte man dann sofort einsetzen und bräuchte nicht erst die eigene Lösung zu entwickeln und herzustellen.

Auch bei der Softwareentwicklung treten bestimmte Probleme und An-forderungen immer wieder auf. Gelingt es nun, rechtzeitig zu erkennen, dass es sich dabei um einen Problembereich (Domain) handelt, für den es bereits eine Lösung gibt, kann diese Lösung ein weiteres Mal verwendet werden. Dies wiederum bedeutet, dass man die Kosten, die zur Lösung des Problems hätten aufgewendet werden müssen, ebenfalls einspart. Dabei ist zu beachten, dass unter Kosten nicht nur die finanziellen Aufwendungen als solche zu verstehen sind, sondern auch die Zeit zur Lösungsfindung, zum Erwerb des benötigten Wissens, zur Implementierung und zum Tes-ten.

In [Bal97, S. 639] werden die folgende Punkte als Vorteile der Wiederverwendung genannt:

- Erhöhung der Produktivität,
- Verbesserung der Qualität der Produkte,
- Verkürzung der Entwicklungszeit und
- Reduzierung der Kosten.

Die Wiederverwendung kann in unterschiedlichem Umfang und auf verschiedenen Ebenen erfolgen. Don Batory, Professor an der University of Texas, hat sie in die folgenden drei Kategorien eingeteilt: [Bat99]

1. SSR (small scale reuse)

Darunter ist alles bis zur Wiederverwendung von einzelnen Algorithmen und Funktion zu verstehen.

2. MSR (medium scale reuse)

Dies bezeichnet die Wiederverwendung von zusammenhängenden Funktionen in Form von Klassen.

3. LSR (large scale reuse)

Hiermit ist alles gemeint, was über die Wiederverwendung von ein- zelnen Klassen hinausgeht. Also der Einsatz von untereinander abhängigen Klassen, von Frameworks oder von Komponenten.

2.4. Wiederverwendung

Bei LSR kann weiterhin unterschieden werden in White-Box-Wiederver-wendung, d.h. die innere Struktur und die Abläufe sind bekannt, und in Black Box-Wiederverwendung, d.h. es sind nur die Schnittstellen bekannt, nicht aber die interne Realisierung. Es gibt auch gemischte Systeme, bei denen der Übergang fließend ist, sodass eine Zuordnung zu nur einem der beiden Extreme nicht möglich ist.

Auf den ersten Blick mag man geneigt sein anzunehmen, dass der Nut-zen umso größer ist, je größer die wiederverwendete Struktur ist. Das ist aber leider nur die halbe Wahrheit. Diesem Nutzen entgegen steht der Aufwand, der betrieben werden muss, um diese Struktur zu verwenden. Zum Einen äußert er sich in der Suche nach einer passenden Komponente oder einem passenden Framework und zum Anderen sind häufig aufwendi-ge Anpassungen und Konfigurationen nötig, bevor man die Komponente bzw. das Framework einsetzen kann. Bei einem gut durchdachten Frame-work bzw. einer gut entworfenen Komponente sollte der Aufwand für die Anpassung aber immer noch weit geringer sein, als der einer völligen Neu-entwicklung. Somit sollten die Vorteile, die durch die Wiederverwendung erzielt werden können, überwiegen.

Don Batory bezieht seine Kategorisierung nur auf die Wiederverwen-dung auf Implementationsebene. Es gibt aber auch eine Wiederverwen-dung auf Entwurfsebene durch den Einsatz von Mustern. Dabei wird kei-ne fertig implementierte Software wiederverwendet, sondern nur die Idee, wie man ein Problem lösen kann. Diese wird in Form eines Konzeptes, ei-ner Vorgehensweise oder einer Architektur beschrieben. Besondere Bedeu-tung hat dabei eine Sammlung von Mustern mit dem Titel Design Pattern (deutscher Titel: Entwurfsmuster) [GHJV96] von ”TheGangofFour“er- langt. Durch die Verbreitung von Mustern ist auch noch ein anderer Effekt zu beobachten. Die Kommunikation zwischen Softwareentwicklern kann mit Hilfe der Muster wesentlich effektiver erfolgen, da bestimmte Design-Strukturen nicht mehr im Detail beschrieben werden müssen, sondern nur noch mit dem Namen des Musters. Somit wird es wesentlich einfacher, sich über bestimmte Design-Konzepte zu verständigen. Entscheidungen können schneller getroffen werden.

Für weiterführende Informationen zum Thema Wiederverwendung sei auf die zahlreichen Artikel und Bücher zu diesem Thema verwiesen. Ab-handlungen sind auch zu finden in: [OSV99a] [Bal97] [Lie96] [Bat99] [Sol99].

2.5. Abstrakte grafische Beschreibungssprache

Die gleichen Vorteile, die für die Nutzung der Wiederverwendung sprechen, gelten auch für den konsequenten Einsatz einer abstrakten grafischen Be-schreibungssprache bei der Analyse und dem Design. Bei einer abstrakten Beschreibungsform lassen sich ÄnderungenamModellschnellerumset-zen und komplexe Systeme können leichter beherrscht werden. Außerdem legt man sich noch nicht auf eine konkrete Programmiersprache oder Ziel-plattform fest und bleibt somit in diesem Punkt flexibel. Für eine grafische Form spricht die Erkenntnis, dass die meisten Menschen grafische Struk-turen schneller erfassen können als alphanumerische Beschreibungen.

Zu empfehlen ist die UML-Notation. Sie ist ein von der OMG² entwi-ckelter Standard für die objektorientierte Modellierung, der sich weitestge-hend durchsetzen konnte [Obj00]. Die UML besteht aus diversen grafischen Elementen, die in unterschiedlichen Diagrammen verwendet werden. So ist es möglich, verschiedene Sichten und Aspekte zu repräsentieren. Außerdem wird die UML-Notation auf breiter Front von den auf dem Markt befind-lichen Programmen für den Softwareentwurf unterstützt. EinenÜberblick zum aktuellen Stand der verfügbaren Werkzeuge zur UML-Modellierung und ein Vergleich ihres Funktionsumfanges ist auf der Web-Seite ”UML Tools“ [Jecni] zu finden. Eine gutes Online-Tutorial wird unter [Jac00] angeboten. Weitere Literatur: [Oes97] [Bur97]

2.6. CASE-Tool

CASE (computer-aided software engineering) bezeichnet die rechnergestütz-te Methode zur Planung, Organisation und Steuerung der Softwareent- wicklung besonders bei großen komplexen Projekten mit einer Vielzahl beteiligter Personen. Der Einsatz von CASE erlaubt es Softwarearchi-tekten, Programmierern, Testern, Projektleitern und dem Management zu jeder Zeit, den aktuellen Stand des Projektes unter den für sie rele-vanten Aspekten einzusehen. Ein wichtiges Hilfsmittel sind dabei die so genannten CASE-Tools. Sie bieten Möglichkeiten zur grafischen Darstel-lung der verschiedenen Sichten in speziellen Diagrammen, basierend auf den UML-Notationsvorschriften. Im Grad der Unterstützung des gesam-ten UML-Standards bestehen aber zurzeit noch erhebliche Unterschiede bei den auf dem Markt befindlichen CASE-Tools. Andererseits ist die UML für einige Aufgabenbereiche noch nicht ausreichend. Daher gibt es einige CASE-Tool-Hersteller, die diesen Mangel mit proprietären Erweiterungen der UML zu beheben versuchen.

Ein großer Nutzen der CASE-Tools ist darin zu sehen, dass sie die Konsistenz zwischen den einzelnen Diagrammen gewährleisten und da-bei helfen, die modellierten Informationen effektiv weiterzuverarbeiten. So können sie automatisch eine Dokumentation erstellen und auf Basis des Klassendiagramms Quellcode in verschiedenen Programmiersprachen generieren. Es handelt sich dabei in den meisten Fällen aber nur um die strukturellen Elemente einer Anwendung und in Einzelfällen auch um Tei-le des Programmsteuerflusses. Ein Großteil der modellierten Informatio-nen bleibt zurzeit noch ungenutzt. Verbreitet sind Generatoren für Java, C++, Delphi und Visual Basic. Die von den Generatoren erzeugten Co-defragmente sind durch den Softwareentwickler zu vervollständigen, um schließlich ein lauffähiges Programm zu erhalten. Ein großes Problem der CASE-Tools ist die Sicherstellung der Konsistenz zwischen UML-Modell und Programmcode. Sie können zwar auf Grundlage des Modells Code ge-nerieren, aber in der anderen Richtung versagen die meisten. Vielen ist es nicht oder nur unzureichend möglich,Änderungen im Code in das UML-Modell aufzunehmen. Das so genannte Reengineering funktioniert in der Regel nur bei vorher vom CASE-Tool-eigenen Codegenerator erzeugten Quellcode. Somit wird ein iteratives Vorgehen, im Zusammenhang mit der Implementierung des Modells, nur schlecht unterstützt.

Die meisten CASE-Tools stellen eine Schnittstelle für den Zugriff auf ihr Repository bereit, um die Modellinformationen auch für andere Werk-zeuge verfügbar zu machen, z.B. für weitere Generatoren. Das in Kapitel 5 vorgestellte Design beschreibt genau solch einen Generator. Desweite-ren entwickelt die OMG derzeit ein Metadatenaustauschformat mit dem Namen XMI³. Es basiert auf XML⁴ und soll eine Möglichkeit schaffen, die Modellinformationen in einer herstellerunabhängigen Form auszutau-schen.

Zusammenfassend ist festzustellen, dass der Einsatz von CASE-Tools bereits heute zur Steigerung der Effizienz bei der Softwareentwicklung beitragen kann. In Zukunft werden sich die positiven Effekte noch verstärken und zu einem massiven Wettbewerbsvorteil führen.

2.7. Softwaregeneratoren

Softwaregeneratoren sind Programme, die ihrerseits wieder Programme oder Fragmente davon erzeugen können. Das Ergebnis der Generierung kann in der Regel durch Konfigurationsmöglichkeiten des Generators an spezielle Bedürfnisse angepasst werden. Durch den Einsatz von Software-generatoren ist es möglich, die Softwareentwicklung weiter zu automati-sieren und dadurch zu beschleunigen. Desweiteren stellen Generatoren ein wirkungsvolles Mittel zur Erhöhung der Qualität von Software dar. Dies alles wird dadurch erreicht, dass Softwaregeneratoren:

- den Programmierer von Routineaufgaben befreien,
- redundante Arbeiten vermeiden helfen,
- den einfachen Einsatz von Spezialistenwissen ermöglichen, da sie eine von Experten optimierte Implementierung generieren können oder die Nutzung neuer Technologien erleichtern,
- die möglichen Fehlerquellen reduzieren und
- den Wartungsaufwand minimieren.

Softwaregeneratoren lassen sich in zwei Gruppen einteilen. Die eine Grup-pe sind die Codegeneratoren, die Folgen von Anweisungen in einer be-stimmten Programmier- oder Beschreibungssprache erzeugen. Die andere Gruppe sind die Anwendungsgeneratoren, welche verschiedene Kompo nenten auf Grund einer menbauen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung².¹.: Rolle der Softwaregeneratoren

In Abbildung 2.1 wird die Rolle der Generatoren bei der Software-entwicklung veranschaulicht. Auf der rechten Seite der Grafik sind die Entwicklungsstufen eines Softwareprodukts bei der traditionellen Imple-mentierung dargestellt. Der Programmierer setzt eine Anforderung oder ein Modell manuell in Programmcode um. Dieser Quellcode wird vom Compiler in Maschinencode übersetzt und vom Linker zu einer Anwendung zusammengefügt.

Codegeneratoren haben das Ziel, dem Programmierer einen Teil der Codeerstellung abzunehmen. Dazu wandeln sie eine abstrakte Beschrei-bung auf Basis bestimmter Transformationsvorschriften in konkreten Pro-grammcode um. Dies können z.B. Klassendeklarationen und Methoden-rümpfe sein. Auf diesem Weg wird auch eine Konsistenz zwischen Modell und Implementierung erreicht. Für einige Anwendungsgebiete existieren auch Codegeneratoren, die den kompletten Programmcode einer Anwen-dung erstellten, der sich bereits compilieren und linken lässt. Dabei han-delt es sich aber in der Regel nur um einen Prototypen, der durch den Programmierer noch zu erweitern ist.

Anwendungsgeneratoren verfügen über einen Pool von Komponen-ten, die miteinander kooperieren können. Der Softwareentwickler konstru-iert seine Anwendung mit diesen Bausteinen. Der Anwendungsgenerator setzt die einzelnen Komponenten dann anhand der Konstruktionsbeschrei-bung unter Beachtung bestimmter Regeln zusammen. So kann er z.B. die Schnittstellen auf Kompatibilität prüfen oder bestimmte Initialisierungen durchführen. Das Ergebnis der Generierung ist eine fertige Anwendung.

Für den Einsatz von Codegeneratoren sind Anwendungsarchitekturen besonders geeignet, bei denen sich die fachlichen Aspekte von den tech-nischen Aspekten trennen lassen, sodass die Anwendung in die folgenden drei Bestandteile aufgeteilt werden kann [MSPT00, Generierungsfähige Softwarearchitekturen]:

- technische Architektur

Die technische Architektur kapselt die technischen Aufgaben, wie Client/Server-Kommunikation, Transaktionsverarbeitung, Objektak-tivierung, Persistenz⁵ und Replikation⁶, vollständig von manuell pro-grammierten Teilen der Fachlogik. Dieser technische Architekturteil

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: Für Generierung geeignete Anwendungsarchitektur

ist frei von spezifischer Fachlogik und in beliebigen Projekten wiederverwendbar.

- Fachlogik

Die manuell programmierte Fachlogik kapselt die gesamte fachliche Komplexität der Anwendung.

- Anbindung

Die generierten Standardoperationen kapseln das Ineinandergreifen von Fachlichkeit und technischer Architektur.

Das Fachmodell beschreibt die anwendungsspezifischen Teile der Architektur. Das sind die unterstützten Daten und ihre Funktionen sowie deren Beziehungen. Das Fachmodell kann z.B. in der UML beschrieben werden und dient dem Codegenerator als Grundlage für die Generierung von Standardmethoden. Das sind zum Beispiel Operationen zum Setzen und Abfragen von Attributen oder zum Erzeugen und Zerstören von Objekten. Die Fachlogik, das Fachmodell und die generierten Standardoperationen bilden die so genannte Business-Objekt-Schicht.

Die Generierung von Software ist ein Thema der Informatik, an welchem schon seit längerer Zeit in zahlreichen Projekten intensiv geforscht wird. Ein Überblick aktueller Entwicklungen und Forschungsschwerpunkte ist in Kapitel 3 zu finden.

2.8. Frameworks

Wie bereits in Abschnitt 2.4 beschrieben, ist mit Frameworks eine Wiederverwendung von Software im großen Rahmen (large scale reuse) möglich. Aber was ist ein Framework?

Ein Framework ist eine Menge von kooperierenden Klassen, die in einer vorgegeben Art und Weise zusammenwirken, um einen bestimm-ten Problembereich abzudecken. Eine Anpassung zur Lösung eines be-stimmten Problems wird durch Spezialisierung der Framework-Klassen erreicht. Das bedeutet, dass der Anwender des Frameworks Unterklassen der Framework-Klassen erstellt und dabei einige der ererbten Methoden neu implementieren oder erweitern kann, um so die gewünschte Anpas-sung für seine Anwendung vorzunehmen. Das Prinzip von Frameworks wird oft mit dem folgenden Satz beschrieben: ”Don´tcalltheframework, the framework calls you.“ Dies soll deutlich machen, dass der Ablauf fest vorgegeben ist. Man hat also keinen Einfluss auf den Zeitpunkt, wann eine Methode ausgeführt wird, sondern nur darauf, was in der Methode aus-geführt wird. Bei der Nutzung von Klassenbibliotheken ist die Situation genau entgegengesetzt. Der Anwendungsentwickler legt den Kontrollfluss im Programm selbst fest. Zu bestimmten Zeitpunkten werden dann Funk-tionen der Bibliothek aufgerufen.

Frameworks fallen in die Kategorie der White-Box-Wiederverwendung, weil der Nutzer des Frameworks die innere Struktur und die Abläufe kennen muss. Bekannte Vertreter dieser Technik sind zum Beispiel die Anwendungsumgebungen (Application-Frameworks) MFC⁷ für die WindowsSysteme und MacApp für die Macintosh-Systeme.

2.9. Domain Engineering

Die Entwicklung eines Frameworks, z.B. für eine spezielle Gruppe von Anwendungen, gestaltet sich als sehr schwierig, da deren Entwicklung ne-ben großem softwaretechnischen Wissen auch ein sehr tiefes Verständnis für das Anwendungsgebiet erfordert (vgl. [BBE95]). Darum ist ein ent-sprechender Zeit- und Kostenaufwand einzukalkulieren. Folgendermaßen kann man dabei vorgehen:

Nach dem Abgrenzen eines Problembereichs (Domain) werden bereits implementierte Lösungen untersucht. Dabei ist das Ziel, die gemeinsamen von den spezifischen Aspekten zu trennen (siehe 2.9 Domain engineering). Die Teile, die in allen Lösungen zu finden sind, werden gekapselt und in einem eigenen Klassen-Design reimplementiert. Der ganze Prozess muss in der Regel mehrmals durchlaufen werden, bevor ein Framework daraus entsteht. Eine ausführliche Beschreibung zum Vorgehen bei der Entwicklung eines Frameworks ist in [Nem00] dargestellt.

2.9. Domain Engineering

Domäne (engl. Domain) ist ein stark strapazierter Begriff. Im Fremdwörterbuch ist dazu die folgende Beschreibung zu finden:

1 ”Arbeits-oderWissensbereich,Spezialgebiet“
2 ”Herrschaftsbereich,Gebiet,eigenerBezirk“
3 ”staatlicherland-oderforstwirtschaftlicherBetrieb,staatlichesLand-gut“

Auch im IT-Bereich⁸ wird der Begriff in verschieden Zusammenhängen verwendet. So bezeichnet er im Kontext mit relationalen Datenmodellen die Menge der möglichen Werte eines Attributes (Spalte der Tabelle). Im Internet ist Domain die Bezeichnung für einen Namensraum. Bei den Be-triebssystemen Windows NT und OS/2 fasst man für Verwaltungszwecke eine Gruppe von Benutzern zu Domains zusammen. Und im Bereich der objektorientierten Softwareentwicklung, in welchem auch die vorliegende Arbeit angesiedelt ist, wird unter Domain ein fachlich abgegrenzter Problembereich verstanden.

Mit Domain Engineering bezeichnet man eine systematische Vorge-hensweise zur Entwicklung wiederverwendbarer Strukturen und ihrer Ele-mente für eine bestimmte Domain. Diese Elemente können Anforderungen, Architekturen, Muster, Komponenten, Klassen oder andere Formen von wiederverwendbarem Entwicklungswissen sein. Beim Domain Engineering wird unter anderem ein Domain Model (Domänenmodell, Fachkonzept-Modell) erstellt, mit welchem die fachlich relevanten Sachverhalte be-schrieben werden. Diese sind die unterstützten Daten und Funktionen und deren Beziehungen.

Ausgehend von verschiedenen Implementierungen zur Lösung der Pro-bleme einer Domain werden Gemeinsamkeiten und Unterschiede heraus-gearbeitet und die variablen Bestandteile ausfindig gemacht. Ziel ist es, eine allgemein gültige Lösung in Form von allgemein gültigen Komponen-ten einschließlich ihrer Interaktionen zu finden. Das Ergebnis von Domain Engineering kann z.B. ein Framework oder eine Komponentenarchitektur sein. In Abbildung 2.3 wird dies an einem einfachen Beispiel verdeutlicht. Bei verschieden vorhandenen Lösungen wurden die Gemeinsamkeiten ge-sucht, extrahiert und in einer Basiskomponente zusammengefasst (LKW-Basis). Diese kann nun durch verschiedene Elemente (LKW-Aufbauten) erweitert werden.

Das Domain Engineering kann in mehrere Phasen unterteilt werden. Diese sind nach Becky Winant [Win99]:

1. Domain Identification

- Erstellen einer kohärenten Menge von Informationen, Regeln, Aktivitäten und Ereignissen, welche die Domain charakterisieren
- Einstufung der Domain gegenüber anderer Domains, Techniken oder Axiomssystemen und Spezifizierung von Abhängigkeiten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3.: Beispiel Domain Engineering

- Anfertigen einer allgemeinen Beschreibung der Domain

2. Domain Analysis

- Benennen und Definieren aller Regeln und Bestimmungen
- Einschränken der notwendigen Aktivitäten
- Exaktes Beschreiben der Schlüsselereignisse - wie werden sie erkannt und wie werden sie beantwortet

3. Domain Mappings

- Deklarieren aller Initialwerte
- Definieren aller Schnittstellen und der möglichen Kommunikation im System

4. Domain Design

- Prüfen auf Anwendbarkeit von Entwurfsmustern
- Herausarbeiten von Zusammengehörigkeit
- Aufteilung in Pakete und Komponenten
- Festlegen von Sichtbarkeit
- Minimieren von Abhängigkeiten und Schnittstellenkomplexität
- Dokumentieren der Designentscheidungen und Schnittstellen

5. Domain Implementation

- Umsetzung in Code durch Generatoren oder manuell

Dabei ist zu beachten, dass die einzelnen Phasen in der Praxis nicht klar getrennt werden können, sondern fließend ineinander übergehen. Außer-dem sollten die Phasen Zwei bis Fünf iterativ durchlaufen werden. Bei der Implementierung hat es sich bewährt, zunächst Prototypen für einen bestimmten Aspekt mit einer dazugehörigen Testumgebung zu erstellen. Erst, wenn alle Testimplemtierungen erfolgreich abgeschlossen sind, sollte das Komplettsystem erstellt werden.

2.10. Praxisbeispiel

Es gibt Softwareprojekte, die nur durch den Einsatz von Codegeneratoren und Frameworks in der vorgegebenen Zeit realisiert werden konnten. Solch ein Projekt wurde in der Fachzeitung ”OBJEKTspektrum“[AKMRT[99]] vorgestellt und soll hier als Beispiel dienen.

Ziel dieses Projektes war es, ein ”Planungs-undDispositionssystem mit einer vierstelligen Zahl von Endnutzern und einer Verteilung über ganz Deutschland“ zu entwickeln, welches besonders hohe Anforderungen an die Performance erfüllt. Dies kann man aber nur erreichen, wenn die technische Plattform optimal auf die fachliche Anwendung zugeschnitten wird. ”BeigroßenProjektenmitlangenProjektlaufzeitenführtdieszu einem Dilemma: Nutzungsprofile und Anforderungen an die technische Plattform sind erst sehr spät bekannt, ändern ihre Definition oder können erst durch Messungen im Pilotbetrieb erhoben werden.“ Diesem Dilemma konnte durch den massiven Einsatz von technischen Frameworks in Kombination mit Codegeneratoren begegnet werden.

Mit Hilfe von Frameworks wurden saubere Schnittstellen, die die Er-weiterbarkeit des Gesamtsystems garantierten, eingeführt. Unter Verwen-dung von selbst entwickelten Codegeneratoren konnte die Integration des fachlichen Modells, welches mit CASE-Tools erstellt wurde, in das Fra-mework erreicht werden. Dazu wurden Informationen über das fachli-che Objektmodell in Form von Metainformationen, die dann zur Laufzeit ausgewertet werden, sowie die Deklaration und Definition von modellier-ten Methoden generiert. Die Methoden setzen die fachlichen Aufrufe des Framework-Kerns um. Dadurch konnten große Codeteile wie Klassener-weiterungen, referenzielle Integrität, vordefinierte Such-, Filter- und Na-vigationsmethoden sowie Indizes deklarativ erzeugt werden. Sollten Ände-rungen an der Implementierung der generierten Programmteile, z.B. aus Performance-Gründen, nötig werden, so reicht ein erneuter Lauf eines an-gepassten Generators, um sie in allen betroffenen Komponenten durch-zuführen.

In diesem Projekt wurde besonders deutlich, welches Potenzial schon heute in dem kombinierten Einsatz von CASE-Tools, Frameworks und Generatoren liegt.

3. Forschungsschwerpunkte

In zahlreichen Forschungsprojekten wird versucht, Methoden und Techni-ken zu entwickeln, die die Softwareerstellung vereinfachen und beschleu-nigen sollen, um so ein neues Niveau in der Softwareentwicklung zu er-reichen. Dazu versucht man entweder bestehende Konzepte zu erweitern oder völlig neue Techniken zu entwickeln. All diesen Bemühungen gemein ist das Ziel, die Komplexität von Softwareprodukten zu minimieren und die Generierungfähigkeit zu maximieren. Einige dieser Forschungsprojekte werden in diesem Kapitel vorgestellt.

Von Prof. Eisenecker¹, Prof. Broy² und Dr. Czarnecki³ wurde 1997 der Arbeitskreis Generative und komponentenbasierte Softwareentwick-lung der GI-Fachgruppe 2.1.9: Objektorientierte Softwareentwicklung⁴ in-itiiert. Damit wurde das Ziel verfolgt, für diesen Themenbereich eine Platt-form zum Austausch von Informationen zu schaffen und Aktivitäten zu bündeln. Unter anderem wurde eine Webseite mit einerÜbersicht zu aus-gewählten Techniken der generativen und komponentenbasierten Software-entwicklung zusammengestellt [Cza00], die einen ersten Einblick in die Problematik geben soll. Außerdem wurde von diesem Arbeitskreis 1999 eine Tagungsreihe mit dem Namen International Symposium on Genera-tive and Component-Based Software Engineering ins Leben gerufen und organisiert.

3. Forschungsschwerpunkte

3.1. Object-Oriented Programming (OOP)

Bei der Objektorientierung fasst man den Zustand (Daten) und das Ver-halten (Methoden, die den Zustand beeinflussen können) zu Einheiten mit eigener Identität zusammen. Eine solche Einheit wird Objekt genannt. Objekte stehen mit anderen Objekten in Beziehung und können unterein-ander Nachrichten austauschen und dadurch bestimmte Aktionen auslösen bzw. ausführen. Die zentralen Konzepte des objektorientierten Ansatzes sind die Polymorphie, die Kapselung und die Vererbung. Polymorphie be-zeichnet die Fähigkeit von Methoden, sich zur Laufzeit auf Objekte ver-schiedener Klassen beziehen zu können. Eine Klasse verkörpert einen Typ von Objekten mit gemeinsamer Struktur und gemeinsamem Verhalten. Durch Kapselung werden die Zugriffe auf Methoden und Eigenschaften durch Objekte bestimmter anderer Klassen eingeschränkt. Vererbung be-deutet die Weitergabe von Eigenschaften und Methoden von einer Ober-zur Unterklasse. Die Vererbung erlaubt die Beschreibung von Klassen-beziehungen im Sinne von Spezialisierung bzw. Generalisierung. [Sie00, Objektorientierte Programmierung]

Die objektorientierte Programmierung wird wegen zahlreicher Vorteile gegenüber der prozeduralen Programmierung schon seit mehreren Jahren in der Softwareentwicklung eingesetzt. Aber auch bei der Objektorientierung zeigten sich einigen Schwächen, die man durch bestimmte Erweiterungen des OO-Konzeptes beseitigen will. Einer dieser neuen Ansätze ist die subjektorientierte Programmierung.

3.2. Subject-Oriented Programming (SOP)

”DerGrundgedankedersubjektorientiertenProgrammierungbestehtdar-in, dass die Bedeutung eines Objektes von seinem Kontext (bzw. Betrachter) abhängig, d.h. subjektiv ist.“ [Cza00] Bei der subjektorientierten Pro-grammierung werden objektorientierte Systeme durch das Zusammenset-zen von Subjekten gebildet. Ein Subjekt ist eine Ansammlung von Klassen

[...]

---

¹ UML = Unified Modeling Language

¹ EDV = elektronische Datenverarbeitung

² OMG = Object Management Group

³ XMI = XML Metadata Interchange Format

⁴ XML = eXtensible Markup Language

⁵ Persistenz = Dauerhaftigkeit

⁶ Replikation = identische Verdopplung

⁷ MFC = Microsoft Foundation Class Library

⁸ IT = Informations-Technologie

¹ FH Heidelberg

² TU München

³ Daimler Chrysler Forschungszentrum in Ulm und TU Ilmenau

⁴ GI = Gesellschaft für Informatik