Automatisierte Softwaregenerierung aus UML-Modellierungsinformationen

Autor: Tobias Lindig

Lindig, Tobias:

Automatisierte Softwaregenerierung aus UML-Modellierungsinformationen / Tobias Lindig - 2000. - Ilmenau, Techn. Univ., Fak. f. Informatik und Automati- sierung, 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

1. Die Wiederverwendung ist ein wirksames Mittel zur Verbesserung

der Qualit¨ at, zur Verk¨ urzung der Entwicklungszeit und zur Senkung des Wartungsaufwandes bei der Entwicklung von Software.

2. Entwurfs- und Architekturmuster erm¨ oglichen eine Wiederverwen-

dung auf der Entwurfsebene und eine effizientere Kommunikation zwischen den Softwareentwicklern.

3. Der komplette Entwurf von Software wird zuk¨ unftig mittels abstrak-

ter Beschreibungssprachen erfolgen. Damit wird ein plattform- und zielsprachenunabh¨ angiges Design erm¨ oglicht.

sein. Basierend auf einem Repository k¨ onnen sie verschiedene Schrit- te in der Softwaerentwicklung unterst¨ utzen und unterschiedliche Sich- ten konsistent darstellen. Das Ergebnis ist eine abstrakte Beschrei- bung.

5. Programmcode und Anwendungen k¨ onnen auf Grundlage der ab-

strakten Modellbeschreibung mit Hilfe von Generatoren automatisch erstellt werden.

dellierung der fachlichen Aspekte beschr¨ anken k¨ onnen. F¨ ur die tech- nischen Aspekte werden vorgefertigte L¨ osungen eingesetzt. Die An- bindung der Fachlogik an die technische Architektur erfolgt durch Generatoren.

7. Aus Punkt 6 folgt, dass Entwickler von technischen L¨ osungen ent- sprechende Generatoren bereitstellen m¨ ussen. Eine flexible Archi- tektur f¨ ur 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¨ ate- re 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

Abbildungsverzeichnis

2.1.  Rolle der Softwaregeneratoren  15

2.2.  F ur Generierung geeignete Anwendungsarchitektur  17

2.3.  Beispiel Domain Engineering  21

4.1.  Klassendiagramm: einfache Klasse  38

4.2.  Klassendiagramm: Vererbung  43

4.3.  Klassendiagramm: Assoziation  44

4.4.  Klassendiagramm: Komposition  46

4.5.  Klassendiagramm: bidirektionale Aggregation  50

5.1.  Kombination verschiedener Module uber eine gemeinsame  

  Schnittstelle  54

5.2.  Komponentendiagramm  55

5.3.  Muster Adapter  58

5.4.  Muster Br ucke  59

5.5.  Muster Singleton  60

5.6.  Muster Abstrakte Fabrik  62

5.7.  Muster Fabrikmethode  63

5.8.  Muster Schablonenmethode  64

5.9.  Struktur  66

5.10.  Objektbaum eines einfachen C -Headers  77

  Inv -Nr : 200 99D 067 Tobias Lindig  ix

Abbildungsverzeichnis

1. Einleitung

1.1. Motivation

Softwareprojekte werden immer gr¨ oßer und komplexer. Die Anforderun- gen an Qualit¨ at und Quantit¨ at nehmen st¨ andig zu. Um im Wettbewerb bestehen zu k¨ onnen, wird intensiv nach Mitteln und Wegen gesucht, die- sen Anforderungen gerecht zu werden. Ein großes Potenzial liegt in der Verbesserung des Entwurfsprozesses, der Wiederverwendung von Softwa- re und der Automatisierung der Applikationserstellung.

solange wie m¨ oglich unabh¨ angig von der sp¨ ateren Implementierung zu bleiben. Dazu bedient man sich abstrakter Beschreibungsformen wie z.B. der UML 1 . 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 Softwa-

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

1. Einleitung

1.2. Aufgabenstellung

Die Aufgabe besteht in der Entwicklung eines Musters f¨ ur einen modular aufgebauten Softwaregenerator mit dem Ziel der automatisierten Erzeu- gung 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 Applikationsgene- rierung, resultierende Einschr¨ ankungen und Abgrenzungen

• Architekturvorschlag; Verwendung von Architektur- bzw. Entwurfs- mustern

• Prototypische Beispielimplementation eines Generators mit Anbin- dung 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 Datenbankzugrif- fe ¨ uber 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¨ art. 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 Forschungs- projekten und Produkten aus dem Umfeld der generativen und komponen- tenbasierten Softwareentwicklung vor.

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

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 er- stellt wurde. Im Abschnitt 5.4, Probleme, werden die Probleme, bei de- nen das Muster angewandt werden kann, explizit aufgef¨ uhrt und in 5.5, L¨ osungen, werden die im Muster verwendeten Probleml¨ osungen und Va- riationsm¨ oglichkeiten im Detail erl¨ autert. Abschnitt 5.6, Struktur, enth¨ alt ein UML-Klassendiagramm, in welchem die Klassen des Musters mit ih- ren Beziehungen dargestellt sind. Abschnitt 5.7, Teilnehmer, beschreibt die Zust¨ andigkeiten 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¨ oglichkeiten auf. Schließlich werden im Abschnitt 5.11, Implementierung, konkrete Hinweise f¨ ur ei- ne Implementierung der Architektur gegeben und mit Beispielen in C++ veranschaulicht.

den Arbeit und eine Spekulation ¨ uber die zuk¨ unftige Entwicklung der Softwareindustrie zu finden.

1. Einleitung

2. Grundlagen

Dieses Kapitel geht auf einige Probleme der Softwareentwicklung und War- tung 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].

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 voraus-

gesetzte 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 Bedin-

gungen.“

• ¨ Anderbarkeit

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

” wendig ist.“

• ¨ Ubertragbarkeit

[...] Eignung der Software, von einer Umgebung in eine andere ” ubertragen zu werden.“ ¨

2.2. Softwarequalit¨ at

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

barkeit zu den inneren Qualit¨ atsmerkmalen.

nem Pflichtenheft definierten Anforderungen relativ leicht zu kontrollie- ren. 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 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¨ 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].

der 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.

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).

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 hin- aus durch die erh¨ ohten Aufwendungen f¨ ur die Wartung noch erschwert. Diese Aufwendungen steigen zurzeit proportional mit der Zahl der ab- geschlossenen Projekte und f¨ uhren zu einem so genannten ” Anwendungs-

stau“ in den EDV-Abteilungen 1 der Unternehmen. Hierdurch werden drin- gend ben¨ otigte Kapazit¨ aten gebunden und k¨ onnen deshalb nicht f¨ ur Neu- entwicklungen 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 be- gegnen 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 Softwareentwick- lung 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¨ oglich- keit, schnell an ver¨ anderte Rahmenbedingungen angepasst zu werden und kann dadurch die Softwarewiederverwendung schon auf der Entwurfsebe- ne unterst¨ utzen. Eine solche Referenzarchitektur wurde im Rahmen dieser Diplomarbeit entwickelt und ist im Kapitel 5 beschrieben.

1 EDV = elektronische Datenverarbeitung

2.4. Wiederverwendung

zu favorisierende L¨ osung.

2.4. Wiederverwendung

Wie zuvor erw¨ ahnt, kann die Wiederverwendung von Software ein effek- tives Mittel zur Erh¨ ohung der Qualit¨ at und zur Verk¨ urzung der Entwick- lungszeit darstellen und somit zur Kostensenkung und Quantit¨ atssteige- rung f¨ uhren.

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

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 Tes- ten.

In [Bal97, S. 639] werden die folgende Punkte als Vorteile der Wieder- verwendung 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 ver- schiedenen 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 Algorith- men 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 ein-

zelnen Klassen hinausgeht. Also der Einsatz von untereinander abh¨ angi- gen 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¨ 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 Nut- zen 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 aufwendi- ge 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 Neu- entwicklung. Somit sollten die Vorteile, die durch die Wiederverwendung erzielt werden k¨ onnen, ¨ uberwiegen.

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¨ 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.

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 Be- schreibungssprache 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 Struk- turen schneller erfassen k¨ onnen als alphanumerische Beschreibungen. Zu empfehlen ist die UML-Notation. Sie ist ein von der OMG 2 entwi- ckelter Standard f¨ ur 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¨ oglich, verschiedene Sichten und Aspekte zu repr¨ asentieren. Außerdem wird die UML-Notation auf breiter Front von den auf dem Markt befind- lichen 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¨ utz- te Methode zur Planung, Organisation und Steuerung der Softwareent-

2 OMG = Object Management Group