Autor: Tobias Lindig

Lindig, Tobias:

Automatisierte Softwaregenerierung aus UML-Modellierungsinformationen / Tobias Lindig - 2000. - Ilmenau, Techn. Univ., Fak. f. Informatik und Automatisierung, Diplomarbeit

2000 Tobais Lindig c

Dieses Werk ist urheberrechtlich gesch¨ utzt. Alle Rechte vorbehalten.

Text, Abbildung und Beispiele wurden mit gr¨ oßter Sorgfalt erarbeitet. Der Autor kann jedoch weder Garantie noch die juristische Verantwortung oder irgendeine Haftung f¨ ur die Nutzung dieser Informationen, f¨ ur deren Wirtschaftlichkeit oder fehlerfreie Funktion f¨ ur einen bestimmten Zweck ¨ ubernehmen.

Die in dieser Arbeit erw¨ ahnten Soft- und Hardwarebezeichnungen sind in den meisten F¨ allen eingetragene Marken und unterliegen als solche den gesetzlichen Bestimmungen.

ii

Thesen

7. Aus Punkt 6 folgt, dass Entwickler von technischen L¨ osungen entsprechende Generatoren bereitstellen m¨ ussen. Eine flexible Architektur f¨ ur solche Generatoren ist das im Rahmen dieser Arbeit entwickelte Frameworkdesign FlexiGen.

8. Durch die Verwendung von FlexiGen erreicht man Wiederverwendung auf Entwurfsebene. Die Architektur selbst ist eine Kombination verschiedener Entwurfsmuster.

9. FlexiGen entkoppelt Generator und CASE-Tool in dem es Genera-tormodule und Adaptermodule definiert. Dadurch wird eine sp¨ atere Erweiterung um neue Generatoren bzw. Anpassung f¨ ur weitere CASE-Tools mit nur minimalem Aufwand erm¨ oglicht. Ilmenau, den 26. Juni 2000

Tobias Lindig

iv

Inhaltsverzeichnis

Thesen   iii

1.  Einleitung  1

1.1.  Motivation  1

1.2.  Aufgabenstellung  2

1.3.  Aufbau dieser Arbeit  2

2.  Grundlagen  5

2.1.  Voraussetzung zum Verst andnis  5

2.2.  Softwarequalit at  6

2.3.  Quantit at  8

2.4.  Wiederverwendung  9

2.5.  Abstrakte grafische Beschreibungssprache  12

2.6.  CASE-Tool  12

2.7.  Softwaregeneratoren  14

2.8.  Frameworks  18

2.9.  Domain Engineering  19

2.10.  Praxisbeispiel  22

3.  Forschungsschwerpunkte  25

3.1.  Object-Oriented Programming (OOP)  26

3.2.  Subject-Oriented Programming (SOP)  26

3.3.  Aspect-Oriented Programming (AOP)  28

3.4.  Adaptive Programming (AP)/Demeter  30

Inv.-Nr.:  200-99D-067 Tobias Lindig  v

Inhaltsverzeichnis

3.5.  Transformationssysteme  31

3.6.  Parametrisierte Typen  32

3.7.  GenVoca  32

3.8.  Generative Programming  33

3.9.  Intentional Programming (IP)  33

3.10.  Generative Softwarekonstruktion  33

3.11.  Softwaregenerator  34

3.12.  Zusammenfassung  36

4.  Umsetzung von UML in Code  37

4.1.  Klassen, Attribute und Methoden  38

4.2.  Vererbung und Schnittstellenimplementierung  42

4.3.  Assoziation  44

4.3.1.  Unidirektional  44

4.3.2.  Bidirektional  49

4.4.  Zusammenfassung  52

5.  Architektur FlexiGen  53

5.1.  Zweck  53

5.2.  Typ  53

5.3.  Motivation  53

5.4.  Probleme  55

5.5.  L osungen  56

5.5.1.  L osung f ur inkompatible Quellen  56

5.5.2.  L osung f ur verschiedene Ausgaben  58

5.5.3.  L osung f ur Dynamik  59

5.5.4.  Erweiterte L osung f ur Dynamik  61

5.5.5.  L osung f ur Codegenerierung  61

5.6.  Struktur  65

5.7.  Teilnehmer  65

5.8.  Interaktionen  69

5.9.  Ablauf  70

5.10.  Konsequenzen  70

vi  Tobias Lindig Inv -Nr :  200-99D-067

Inhaltsverzeichnis

5.11.  Implementierung  71

5.11.1.  Statischer Singleton  71

5.11.2.  Manager  72

5.11.3.  Adapter  74

5.11.4.  Generator  75

5.12.  Bekannte Verwendungen  78

6.  Zusammenfassung  79

6.1.  Spekulation uber die zuk unftige Entwicklung  80

A.  Namenskonventionen  83

B.  Glossar  85

Literaturverzeichnis   95

Erkl  arung  101

Inv.-Nr.:  200-99D-067 Tobias Lindig  vii

Inhaltsverzeichnis

viii Tobias Lindig Inv.-Nr.: 200-99D-067

Abbildungsverzeichnis

Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Inv.-Nr.: 200-99D-067 Tobias Lindig ix

Abbildungsverzeichnis

x Tobias Lindig Inv.-Nr.: 200-99D-067

1. Einleitung

1.1. Motivation

Softwareprojekte werden immer gr¨ oßer und komplexer. Die Anforderungen an Qualit¨ at und Quantit¨ at nehmen st¨ andig zu. Um im Wettbewerb bestehen zu k¨ onnen, 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¨ oglich unabh¨ angig von der sp¨ ateren Implementierung zu bleiben. Dazu bedient man sich abstrakter Beschreibungsformen wie z.B. der UML ¹ . Auf Grundlage dieser abstrakten Modelle ist es m¨ oglich, Teile des Programmcodes automatisch zu erzeugen. Diese Entwicklung steht aber erst an ihrem Anfang.

In dieser Diplomarbeit wird auf die Vor- und Nachteile der Softwaregenerierung eingegangen und ein ¨ Uberblick ¨ uber den aktuellen Stand

der Entwicklung gegeben. Weiterhin wird eine Architektur f¨ ur einen flexiblen 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¨ at und Erweiterbarkeit des Generators gelegt. So k¨ onnen z.B. verschiedene CASE-Tools unterst¨ utzt und verschiedene Arten von Code generiert werden.

¹ UML = Unified Modeling Language

Inv.-Nr.: 200-99D-067 Tobias Lindig 1

1. Einleitung

1.2. Aufgabenstellung

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

• Untersuchung vorhandener Ans¨ atze und L¨ osungen zur generativen Programmierung

• Betrachtungen zur Realisierbarkeit automatischer Applikationsgenerierung, resultierende Einschr¨ ankungen und Abgrenzungen

• Architekturvorschlag; Verwendung von Architektur- bzw. Entwurfsmustern

• Prototypische Beispielimplementation eines Generators mit Anbindung an f¨ uhrende kommerzielle CASE-Tools, wie Rational Rose, SE-LECT Enterprise und OTW. (Speziell zur Erzeugung aller von einer modellierten Applikation ben¨ otigten Codeteile f¨ ur Datenbankzugriffe ¨ uber das Produkt GRIT Connect der Firma GFT Systems GmbH )

1.3. Aufbau dieser Arbeit

Im Kapitel 2, Grundlagen, wird auf die Notwendigkeit der Wiederverwendung von Software eingegangen, und es werden einige Begriffe und Techniken erkl¨ art. Das Kapitel schließt mit einem Praxisbeispiel, bei welchem CASE-Tools, Frameworks und Codegeneratoren erfolgreich eingesetzt 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¨ autert, wie die Umsetzung der Elemente eines UML-Klassendiagramms in C++-Programmcode erfolgen kann. 2 Tobias Lindig Inv.-Nr.: 200-99D-067

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¨ oglichkeiten die Architektur bietet und um welche Art von Architektur es sich handelt. Abschnitt 5.3, Motivation, beschreibt ein Anwendungsproblem, f¨ ur das auf Basis des Musters eine L¨ osung erstellt wurde. Im Abschnitt 5.4, Probleme, werden die Probleme, bei denen das Muster angewandt werden kann, explizit aufgef¨ uhrt und in 5.5, L¨ osungen, werden die im Muster verwendeten Probleml¨ osungen und Variationsm¨ oglichkeiten im Detail erl¨ autert. Abschnitt 5.6, Struktur, enth¨ alt ein UML-Klassendiagramm, in welchem die Klassen des Musters mit ihren Beziehungen dargestellt sind. Abschnitt 5.7, Teilnehmer, beschreibt die Zust¨ andigkeiten der am Muster beteiligten Klassen bzw. ihrer Objekte. Die Zusammenarbeit der Objekte wird im Abschnitt 5.8, Interaktionen, beschrieben und die Reihenfolge der Aktionen bei der Nutzung der Objekte im Abschnitt 5.9, Ablauf. Der Abschnitt 5.10, Konsequenzen, diskutiert einige Vor- und Nachteile, die sich bei der Anwendung des Musters ergeben, und zeigt einige Variationsm¨ oglichkeiten auf. Schließlich werden im Abschnitt 5.11, Implementierung, konkrete Hinweise f¨ ur eine Implementierung der Architektur gegeben und mit Beispielen in C++ veranschaulicht.

den Arbeit und eine Spekulation ¨ Softwareindustrie zu finden.

Inv.-Nr.: 200-99D-067 Tobias Lindig 3

1. Einleitung

4 Tobias Lindig Inv.-Nr.: 200-99D-067

2. Grundlagen

Dieses Kapitel geht auf einige Probleme der Softwareentwicklung und Wartung ein. Dazu wird beschrieben, was unter Softwarequalit¨ at 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¨ utzen. Das Kapitel schließt mit einem Beispiel aus der Praxis, bei welchem ein wesentlicher Grund f¨ ur den Erfolg des Projektes der Einsatz von Frameworks und Codegeneratoren war.

2.1. Voraussetzung zum Verst¨ andnis

Die vorliegende Arbeit ist im Bereich der objektorientierten Softwareent-wicklung angesiedelt. Somit basiert sie auf den dort verwendeten Grund-begriffen und Annahmen. Das Verst¨ andnis 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¨ ur 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¨ ur das Verst¨ andnis der Arbeit erforderlich, mit die-ser Notation vertraut zu sein. Auch wird ein grunds¨ atzliches Verst¨ and-nis f¨ ur das Prinzip von Entwurfsmustern vorausgesetzt. Bez¨ uglich UML ist z.B. [Oes97] zu empfehlen, das Standardwerk f¨ ur Entwurfsmuster ist [GHJV96]. Inv.-Nr.: 200-99D-067 Tobias Lindig 5

2. Grundlagen

2.2. Softwarequalit¨ at

In der DIN-Norm [DINb, 2.1] wird Qualit¨ at folgendermaßen definiert:

Qualit¨ at ist die Gesamtheit von Merkmalen einer Betrach-”

tungseinheit bez¨ uglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erf¨ ullen.“

F¨ ur Software sind in der DIN-Norm [DINa] folgende Qualit¨ atsmerkmale definiert:

• Funktionalit¨ at

[...] Vorhandensein einer Menge von Funktionen, die festgelegte

”

oder vorausgesetzte Erfordernisse erf¨ ullen.“

• Zuverl¨ assigkeit

[...] F¨ ahigkeit der Software, ihr Leistungsniveau unter festgelegten

”

Bedingungen ¨ uber einen festgelegten Zeitraum zu bewahren.“

• Benutzbarkeit

[...] Aufwand, der zur Benutzung der Software erforderlich ist, so-

”

wie die individuelle Bewertung einer solchen Benutzung durch eine festgelegte oder vorausgesetzte Gruppe von Benutzern.“

• Effizienz

[...] Verh¨ altnis zwischen dem Leistungsniveau der Software und dem

”

Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.“

• ¨ Anderbarkeit

[...] Aufwand, der zur Durchf¨ uhrung vorgegebener ¨ Anderungen not-

”

wendig ist.“

• ¨ Ubertragbarkeit

[...] Eignung der Software, von einer Umgebung in eine andere

”

ubertragen zu werden.“ ¨ 6 Tobias Lindig Inv.-Nr.: 200-99D-067

Dabei z¨ ahlen Funktionalit¨ at, Zuverl¨ assigkeit, Benutzbarkeit und Effizienz zu den ¨ außeren Qualit¨ atsmerkmalen sowie ¨ Anderbarkeit und ¨ Ubertragbarkeit zu den inneren Qualit¨ atsmerkmalen.

Die Erf¨ ullung der ¨ außeren Qualit¨ atsmerkmale ist anhand der in einem Pflichtenheft definierten Anforderungen relativ leicht zu kontrollieren. Hingegen lassen sich die inneren Qualit¨ atsmerkmale nur schwer bei der Abnahme der Software vom Auftraggeber ¨ uberpr¨ ufen. Aber genau

diese inneren Qualit¨ atsmerkmale haben einen entscheidenden Einfluss auf die Kosten beim Einsatz der Software. Zahlreiche Studien kommen zu dem Ergebnis, dass der weitaus gr¨ oßte Teil der im Bereich der Software 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¨ oren auch T¨ atigkeiten, die eine bestehende Anwendung verbessern, optimieren, reparieren oder ¨ uberpr¨ ufen, mit dem Ziel, die Anwendung weiterhin bzw. besser nutzen zu k¨ onnen [Oes00, Glossar].

Mangelhafte Qualit¨ at der Software f¨ uhrt aber nicht erst beim Anwender zu h¨ oheren Kosten, sondern auch schon beim Entwickler. So stellen die Kosten f¨ ur die Beseitigung von Produktm¨ angeln in der Regel direkt entgangenen Gewinn dar. Der Zeitaufwand f¨ ur die Beseitigung ist umso gr¨ oßer, je komplexer und unstrukturierter ein Programm ist. Somit sollte es im Interesse aller Beteiligten liegen, Software mit einer hohen Qualit¨ at zu erstellen. Leider ist es aber so, dass qualitativ hochwertige Software zwar in der Wartung g¨ unstiger ist, aber in der Erstellung einen gewissen Mehraufwand verlangt und somit schon am Anfang h¨ ohere Investitionen erfordert.

Eine vielversprechende effektive M¨ oglichkeit, sowohl die Qualit¨ at der Software zu steigern, als auch die Kosten f¨ ur deren Erstellung zu senken, ist durch den Einsatz von Softwarekomponenten bzw. von Softwaregenerie-rung gegeben. Anstelle der komplett neuen Programmierung einer eigenen L¨ osung setzt man so auf die Wiederverwendung von Software und kann somit auch von den Vorz¨ ugen der Wiederverwendung profitieren (siehe 2.4 Wiederverwendung). Inv.-Nr.: 200-99D-067 Tobias Lindig 7

2. Grundlagen

2.3. Quantit¨ at

Die Anforderung an die Quantit¨ at ¨ außert sich darin, dass immer gr¨ oßere Projekte in immer k¨ urzerer Zeit zu realisieren sind. Dies wird dar¨ uber hinaus durch die erh¨ ohten Aufwendungen f¨ ur die Wartung noch erschwert. Diese Aufwendungen steigen zurzeit proportional mit der Zahl der abgeschlossenen Projekte und f¨ uhren zu einem so genannten ” Anwendungsstau“ in den EDV-Abteilungen ¹ der Unternehmen. Hierdurch werden dringend ben¨ otigte Kapazit¨ aten gebunden und k¨ onnen deshalb nicht f¨ ur Neuentwicklungen eingesetzt werden. [OSV99a]

Diese Problematik ist schon seit einiger Zeit bekannt und der Hinter-grund 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]:

Erstens m¨ ussen offene Softwarearchitekturen in Form von Ar-

”

chitekturfamilien herausgearbeitet werden, die unbedingt auf der Wiederverwendung von Softwarekomponenten beruhen.“

Zweitens m¨ ussen korrekte Analyse- und Entwurfsmethoden

”

zur Synthese und Verifikation solcher Softwarearchitekturen eingesetzt werden, die eine ingenieurm¨ aßige Softwareentwicklung erm¨ oglichen.“

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¨ osung bietet die M¨ oglichkeit, schnell an ver¨ anderte Rahmenbedingungen angepasst zu werden und kann dadurch die Softwarewiederverwendung schon auf der Entwurfsebene unterst¨ utzen. Eine solche Referenzarchitektur wurde im Rahmen dieser Diplomarbeit entwickelt und ist im Kapitel 5 beschrieben.

¹ EDV = elektronische Datenverarbeitung

8 Tobias Lindig Inv.-Nr.: 200-99D-067

zu favorisierende L¨ osung.

2.4. Wiederverwendung

Wie zuvor erw¨ ahnt, kann die Wiederverwendung von Software ein effektives Mittel zur Erh¨ ohung der Qualit¨ at und zur Verk¨ urzung der Entwicklungszeit darstellen und somit zur Kostensenkung und Quantit¨ atssteigerung f¨ uhren.

Was verbirgt sich hinter diesen Effekten und wodurch k¨ onnen sie erzielt werden? Einfach gesagt, durch die Wiederverwendung wird Redundanz vermieden, d.h. es wird versucht, das ” Rad“ nicht noch ein weiteres Mal zu erfinden. Zur Veranschaulichung folgendes Beispiel:

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¨ ur den es bereits eine L¨ osung gibt, kann diese L¨ osung ein weiteres Mal verwendet Inv.-Nr.: 200-99D-067 Tobias Lindig 9

2. Grundlagen

werden. Dies wiederum bedeutet, dass man die Kosten, die zur L¨ osung des Problems h¨ atten aufgewendet werden m¨ ussen, 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¨ osungsfindung, zum Erwerb des ben¨ otigten Wissens, zur Implementierung und zum Testen.

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

• Erh¨ ohung der Produktivit¨ at,

• Verbesserung der Qualit¨ at der Produkte,

• Verk¨ urzung 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¨ angenden Funktionen in Form von Klassen.

3. LSR (large scale reuse) Hiermit ist alles gemeint, was ¨ uber die Wiederverwendung von einzelnen Klassen hinausgeht. Also der Einsatz von untereinander abh¨ angigen Klassen, von Frameworks oder von Komponenten. 10 Tobias Lindig Inv.-Nr.: 200-99D-067

Bei LSR kann weiterhin unterschieden werden in White-Box-Wiederverwendung, d.h. die innere Struktur und die Abl¨ aufe 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 ¨ Ubergang fließend ist, sodass eine Zuordnung zu nur einem der beiden Extreme nicht m¨ oglich ist.

Auf den ersten Blick mag man geneigt sein anzunehmen, dass der Nutzen umso gr¨ oßer ist, je gr¨ oß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 ¨ außert er sich in der Suche nach einer passenden Komponente oder einem passenden Framework und zum Anderen sind h¨ aufig aufwendige Anpassungen und Konfigurationen n¨ otig, bevor man die Komponente bzw. das Framework einsetzen kann. Bei einem gut durchdachten Frame-work bzw. einer gut entworfenen Komponente sollte der Aufwand f¨ ur die Anpassung aber immer noch weit geringer sein, als der einer v¨ olligen Neuentwicklung. Somit sollten die Vorteile, die durch die Wiederverwendung

erzielt werden k¨ onnen, ¨

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¨ osen 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 ” The Gang of Four“ 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¨ ussen, sondern nur noch mit dem Namen des Musters. Somit wird es wesentlich einfacher, sich ¨ uber bestimmte Design-Konzepte zu verst¨ andigen. Entscheidungen k¨ onnen schneller getroffen werden. Inv.-Nr.: 200-99D-067 Tobias Lindig 11

2. Grundlagen

F¨ ur weiterf¨ uhrende Informationen zum Thema Wiederverwendung sei auf die zahlreichen Artikel und B¨ ucher 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¨ ur die Nutzung der Wiederverwendung sprechen, gelten auch f¨ ur den konsequenten Einsatz einer abstrakten grafischen Beschreibungssprache bei der Analyse und dem Design. Bei einer abstrakten Beschreibungsform lassen sich ¨ Anderungen am Modell schneller umset-

zen und komplexe Systeme k¨ onnen 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¨ ur eine grafische Form spricht die Erkenntnis, dass die meisten Menschen grafische Strukturen schneller erfassen k¨ onnen als alphanumerische Beschreibungen. Zu empfehlen ist die UML-Notation. Sie ist ein von der OMG ² entwickelter Standard f¨ ur die objektorientierte Modellierung, der sich weitestgehend durchsetzen konnte [Obj00]. Die UML besteht aus diversen grafischen Elementen, die in unterschiedlichen Diagrammen verwendet werden. So ist es m¨ oglich, verschiedene Sichten und Aspekte zu repr¨ asentieren. Außerdem wird die UML-Notation auf breiter Front von den auf dem Markt befindlichen Programmen f¨ ur den Softwareentwurf unterst¨ utzt. Einen ¨ Uberblick

zum aktuellen Stand der verf¨ ugbaren 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¨ utzte Methode zur Planung, Organisation und Steuerung der Softwareent-

² OMG= Object Management Group

12 Tobias Lindig Inv.-Nr.: 200-99D-067