Analyse eines effizienten Werkzeuges zur Modellierung von Software Systemen

Diplomarbeit , 2003 , 155 Seiten , Note: GUT +

Informatik - Software

Software – Engineering, das sich mit dem Entwickeln von Software – Systemen beschäftigt, hat sich seit dem Entstehen der ersten Programmiersprachen bis hin zur heutigen Softwareentwicklung sehr rasch weiterentwickelt.
Die immerzu steigende Komplexität von Softwaresystemen und die hohen Erwartungen an eine Software sind zwei Hauptgründe für diese rasche Weiterentwicklung. Während in der Zeit von 1942 – 1945 (Entwicklung des ersten Computers und der ersten Programmiersprache durch Konrad Zuse), vornehmlich einzelne Recheneinheiten programmiert wurden, wird heute unter Software – Engineering die Fähigkeit verstanden, komplexe Zusammenhänge in Teilprobleme zu unterteilen, jedes Teilproblem zu lösen und alle Teilprobleme wieder zusammenzusetzen, sodass schlussendlich die Lösung des komplexen Problems entsteht.
Vorliegende Arbeit beschäftigt sich einführend mit dem Begriff Software – Engineering und versucht einen Einblick in Modellierung resp. Modellbildungen in der Software – Technik zu geben. Es wird dabei aufgezeigt, wie essentiell Modellbildungen (=die komplexe Umwelt in Computermodellen wiederzugeben) für die Informatik resp. für das Software – Engineering sind.
Für solche Modellbildungen gibt es verschiedene Modellierungssprachen, welche diese Modelle versuchen zu standardisieren.
Die UML (Unified Modelling Language) ist die wichtigste Modellierungssprache und weltweit von Wissenschaft und Wirtschaft als Industriestandard anerkannt.
Nicht nur die UML mit all ihren Diagrammen werden in vorliegender Arbeit detailliert beschrieben, sondern auch die Wichtigkeit der Modellierung von Software – Systemen in den beiden Softwareentwicklungsphasen Analyse und Entwurf aufgezeigt [vgl. Suzu99].
Unterstützend zur Modellierung werden sog. UML Werkzeuge eingesetzt. Aus den unzähligen sich auf dem Markt befindenden UML Werkzeugen werden drei detailliert untersucht:
Anhand einer Aufgabenstellung im Bereich Flughafenleitsystem werden diese drei Werkzeuge evaluiert und abschließend bewertet. Ausgehend von diesen Bewertungen wird schließlich ein Kriterienkatalog für ein zukünftiges professionelles UML Werkzeug definiert.

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Vorgangsweise
1.3 Gliederung der Arbeit
1.4 Schreibweise und Modellierung der Diagramme

2 Software –Engineering und Modellierung
2.1 Einleitung
2.2 Software – Engineering
2.2.1 Historie der Software – Engineering
2.2.2 Definition des Begriffs „Software – Engineering“
2.3 Prinzipien des Software Engineering
2.3.1 Vorgehensmodelle in der Softwareentwicklung
2.3.2 Die Analyse – und Entwurfsphase in der Objektorientierung
2.3.3 Personen in Softwareprojekten
2.3.4 Dokumente und Produkte eines Softwareprojektes
2.4 Modelle in der Software Engineering
2.4.1 Modellierung in der Informatik
2.5 Zusammenfassung

3 UML (Unified Modelling Language)
3.1 Einleitung
3.2 Historie der UML
3.3 Diagrammarten in der UML
3.3.1 Anwendungsfalldiagramm
3.3.1.1 Anwendungsfallbeschreibung
3.3.2 Klassendiagramm
3.3.2.1 Klassen
3.3.2.2 Attribute
3.3.2.3 Methoden
3.3.2.4 Abstrakte Klassen
3.3.2.5 Schnittsellenklasse
3.3.2.6 Assoziationen
3.3.2.7 Binäre Assoziation
3.3.2.8 Aggregation
3.3.2.9 Komposition
3.3.2.10 Weitere Assoziationsformen
3.3.2.11 Objekte
3.3.3 Verhaltensdiagramme
3.3.4 Implementierungsdiagramme

4 UML Werkzeuge
4.1 Einleitung
4.1.1 Aufbau der folgenden Evaluierung:
4.1.2 Aufgabenstellung
4.1.3 Zur Auswahl der UML Tools
4.2 Visio
4.2.1 Einleitung
4.2.2 Modellierung
4.2.3 Evaluierung
4.3 Rational Rose
4.3.1 Einleitung
4.3.2 Modellierung
4.3.3 Evaluierung
4.4 ArgoUML
4.4.1 Einleitung
4.4.2 Modellierung
4.4.3 Evaluierung
4.5 Auswertung der Evaluierungen

5 Anforderungen an ein professionelles UML Werkzeug
5.1 Einleitung
5.2 Erwerb und Installation der Software
5.3 UML Konformität
5.4 Zwingende Reihenfolge bei der Modellierung
5.5 Konsistenzprüfung
5.6 Diagrammdarstellung am Bildschirm
5.7 Roundtripengineering
5.8 Reports und Dokumentation über UML
5.9 Verlinkung der Diagramme
5.10 Druckausgabe
5.11 Repository
5.12 Benutzerschnittstelle
5.12.1 Online Hilfe
5.12.2 Interaktion zwischen Anwender und Werkzeug
5.13 Multiuserfähigkeit
5.14 Erweiterungsmöglichkeiten
5.15 Erstellung von Softwareprojektmanagement – Diagrammen
5.16 Schlussfolgerung

6 Zusammenfassung und Ausblick
6.1 Zusammenfassung
6.2 Ausblick

Anhang: Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 Wasserfallmodell [nach Page01, Wasserfallmodell]

Abbildung 2 Spiralmodell [vgl. Kahl01]

Abbildung 3 Unified Process [vgl. Jaco99]

Abbildung 4 Projektplan

Abbildung 5 Systemarchitektur

Abbildung 6 Kontrollflussdiagramm (if .. then Anweisung)

Abbildung 8 Modellbildung

Abbildung 9 Geschichte UML, in Anlehnung an [Oest02]

Abbildung 10 Anwendungsfalldiagramm

Abbildung 11 Klasse mit Methoden & Attributen

Abbildung 12 Abstrakte Klasse {abstract}

Abbildung 13 Schnittstellenklasse [Oest02, S.33]

Abbildung 14 1..* Kardinalität

Abbildung 15 Aggregation

Abbildung 16 Komposition

Abbildung 17 Gerichtete Assoziation

Abbildung 18 Assoziierte Assoziationen [Vgl. Mart00, S.88]

Abbildung 19 Umwandlung Ass. Klasse in Echte Klasse [Vgl. Mart00, S.88]

Abbildung 20 Abgeleitete Assoziationen

Abbildung 21 Mehrgliedrige Assoziationen

Abbildung 22 gewöhnliche binäre Assoziation

Abbildung 23 Qualifizierte Assoziation

Abbildung 24 Mögliche Darstellungsarten von Objekten

Abbildung 25 Zustandsdiagramm [Zuse01, S. 112]

Abbildung 26 Zustandsdiagramm - Sammelzustand

Abbildung 27 Aktivitätsdiagramm

Abbildung 28 Kollaborationsdiagramm in Anlehnung an [Oest02]

Abbildung 29 Sequenzdiagramm

Abbildung 30 Verteilungsdiagramm

Abbildung 31 Clip Arts Darstellung

Abbildung 32 Benutzeroberfläche von Visio

Abbildung 33 Anwendungsfall mit Visio

Abbildung 34 Klassendiagramm mit Visio

Abbildung 35 Zustandsdiagramm für Szenario „Bewegung anfordern“

Abbildung 36 Benutzeroberfläche von Rational Rose

Abbildung 37 Anwendungsfalldiagramm mit Rational Rose

Abbildung 38 Klassendiagramm mit Rational Rose

Abbildung 39 Zustandsdiagramm mit Rational Rose

Abbildung 40 Benutzeroberfläche ArgoUML

Abbildung 41 Anwendungsfalldiagramm mit ArgoUML

Abbildung 42 Klassendiagramm mit ArgoUML

Abbildung 43 Zustandsdiagramm mit ArgoUML

Abbildung 44 Bewertung UML Werkzeuge

Abbildung 45 Installationsassisten

Abbildung 46 Compilerinstallation

Abbildung 47 Manuelle Einstellung des Compilers

Abbildung 48 Modellierung eines Anwendungsfalldiagramms

Abbildung 49 Meldung über nicht Einhaltung der Reihenfolge

Abbildung 50 Doppelte Bennenung zweier Akterue

Abbildung 51 Namenskonflikt zweier Akterue

Abbildung 52 Klassenänderung in der Entuwrfphase

Abbildung 53 Änderung einer Klasse in der Analysephase

Abbildung 54 Abstraktionsgrad einstellen

Abbildung 55 Umrundete Darstellung zweier sich schneidender Linien

Abbildung 56 Überschneidung Linie mit Element

Abbildung 57 Überschneidung Linie mit Text

Abbildung 58 Eindeutige Zuordnung der Kantenbeschriftungen

Abbildung 59 Codegenerierung

Abbildung 60 Benutzerschnittstelle

Tabellenverzeichnis

Tabelle 1 Systemschnittstellenbeschreibung

Tabelle 2 Black Box Testfall

Tabelle 3 Anwendungsfallbeschreibung „Prüfung“

Tabelle 4 Vergleich der objektorientierter Terminologie [Mart99, S.356]

Tabelle 5 Beispiele für Multiplizitätsangaben

Tabelle 6 Bezeichnung Klasse – Objekt

Tabelle 7 Auswertung UML Werkzeuge

1 Einleitung

1.1 Motivation

So wie in vielen Teilbereichen der Informatik wird auch in der jungen Ingenieursdisziplin Software – Engineering versucht, so weit als möglich eine Automatisierung im Softwareentwicklungsprozess zu erzielen. Selbstverständlich kann bei dieser Tätigkeit die Intelligenz des Menschen und die menschliche Abstraktionsfähigkeit nie ganz kompensiert und maschinell automatisiert werden. Dennoch befinden sich jetzt schon sehr gute Ansätze (wie z.B. künstliche Intelligenz oder für die Erstellung von Sourcecode WYSIWYG Editoren u.a.), welche die monotone Arbeit dem Menschen abnehmen, sodass sich dieser ganz den kreativen und komplexen Anforderungen widmen kann.

Das Ziel bei der Erstellung von Software ist, die Planung so genau wie möglich zu spezifizieren, sodass die schwierige Programmierung von Programmieren, ja sogar von dafür entworfener Software, erfolgt.

„Software soll von Software entwickelt werden!“

Für das Erreichen des obigen Ziels wird speziell in den Softwareentwicklungsphasen Analyse und Entwurf, in denen der Grundstein für das zu entwerfende Softwaresystem gelegt wird, angesetzt.

Wie bereits erwähnt, kann jedoch die menschliche Abstraktionsfähigkeit, oder die Fähigkeit, komplexe Zusammenhänge zu erkennen und Lösungen zu generieren, nie von Software selbst ersetzt werden. Es ist aber durchaus legitim, Software zu erstellen, die wiederum bei der Entwicklung von Software den Menschen ergänzt. Die Anzahl dieser sog. Softwarewerkzeuge im Bereich des Software – Engineering und im Speziellen in der Planung und Spezifikation von Software ist sehr dicht. Da eine ständige Weiterentwicklung besteht, ist eine Sättigung des Marktes in absehbarer Zeit auch nicht zu erwarten.

Bevor allerdings ein Softwarewerkzeug entwickelt werden kann, ist eine standardisierte Modellierungssprache Voraussetzung. Da sich die Modellierungssprache UML – Unified Modelling Language (siehe Kapitel 3) in letzter Zeit als solche bewährt hat, haben diese Software Werkzeuge (im folgenden UML Werkzeuge genannt) UML als Basis. Wie in Kapitel 3 noch genauer

beschrieben wird, ist UML bereits ein Industriestandard. Die rasante Entwicklung im Bereich der UML Werkzeuge ist der Grund dafür, dass (noch) keine Standardisierung existiert. Dies erklärt auch die hohe Anzahl und vor allem die wesentlichen Unterschiede unter den UML Werkzeugen selber.

Obwohl zwar mit UML 2.0 eine Standardisierung der UML Werkzeuge vorgesehen ist, greift diese vorliegende Arbeit diesem Vorhaben der OMG (siehe Kapitel 3) vor: Diese Arbeit versucht, anhand von Evaluationskriterien (Kapitel 4), allgemeingültige Kriterien für ein standardisiertes, professionelles UML Werkzeug zu definieren.

Die wesentlichen zwei Ziele dieser Arbeit sind also, einerseits den verschiedenen Entwicklungsfirmen von UML Werkzeugen einen zusätzlichen Anforderungskatalog darzulegen und andererseits eine Standardisierung von UML Werkzeuge zu erzielen.

1.2 Vorgangsweise

Der erste Schritt besteht darin, die Wichtigkeit von Modellen resp. Modellbildungen für abstrakte Problemstellungen in der Informatik aufzuzeigen und zu erläutern. Ausgehend von der erworbenen Erkenntnis wird im Speziellen in die Softwareentwicklungsphasen Analyse und Entwurf detailliert eingegangen.

Obwohl sich die standardisierte Modellierungssprache UML sehr bewährt hat, wird sie in der Praxis nur selten eingesetzt. Dies resultiert vor allem von der zu geringen Kenntnis über alle UML – Diagrammarten und die damit verbundenen Möglichkeiten. Auch die nicht zufrieden stellende Benutzerakzeptanz ist ein Grund dafür, dass die UML zu selten bei der Softwareentwicklung eingesetzt wird. Bevor in der vorliegenden Arbeit UML Werkzeuge evaluiert wurden, wurden vorerst alle wichtigen UML Diagramme anhand von Beispielen und Abbildungen erklärt.

Der darauf folgende Meilenstein bei der Erstellung dieser Arbeit war ein eingehendes Literaturstudium zu UML Werkzeugen. Wie bereist erwähnt, besteht die Schwierigkeit darin, einen „Quasistandard“ und somit ernsthafte Literatur über UML Werkzeuge zu finden. Neben den eher subjektiven Meinungen der einzelnen Herstellerfirmen gibt es auch sehr gute „private“ Organisationen wie http://www.jeckle.de mit dem Initiator Mario Jeckle, dem ich auf diesem Weg mein Dank aussprechen möchte, die versuchen, bestehende UML Werkzeuge zu analysieren und Richtlinien für zukünftige aufzustellen. Für Interessierte bietet oben erwähnte Plattform reichlich Information und weiterführende Literatur zu UML Werkzeugen und UML im Allgemeinen.

Der abschließende Meilenstein bei der Erstellung dieser Arbeit ist der Anforderungskatalog an ein professionelles UML Werkzeug: Ausgehend von den definierten Evaluationskriterien wurde versucht, ein zukünftiges UML Werkzeug zu entwerfen. Die größte Schwierigkeit bei der Erstellung solcher Werkzeuge ist sicherlich, eine gute Synergie zwischen Benutzerfreundlichkeit und Funktionalität zu erzielen. Der Anforderungskatalog, welcher in Kapitel 5 aufgestellt wurde, stellt Grundlage für ein zukünftiges professionelles UML Werkzeug dar.

1.3 Gliederung der Arbeit

- Kapitel „Einleitung“

Eingeleitet wird dieses Kapitel mit der Beschreibung der Motivation und Vorgangsweise, die für das Verfassen dieser Arbeit ausschlaggebend waren. Es wird einerseits die Dringlichkeit einer sorgfältigen Planung von Softwareprojekten und andererseits die Wichtigkeit der dabei unterstützenden Werkzeuge erläutert.

- Kapitel „ Software – Engineering und Modellierung“

Hier wird zuerst in die Historie der Softwareentwicklung resp. der objektorientierten Softwareentwicklung näher eingegangen. Außerdem wird der Begriff „Software – Engineering“ definiert. Ein weiterer Teil dieses Kapitel beschäftigt sich mit den Prinzipien des Software – Engineering. Mit diesen sind Vorgehensmodelle und Produkte des Softwareentwicklungsprozesses gemeint.

Anschließend wird der Begriff Modell in der Softwareentwicklung definieret und die verschiedenen bestehenden Softwareentwicklungsvorgehensweisen beschrieben.

Abschließend werden die objektorientierten Softwareentwicklungsphasen Analyse und Entwurf erörtert.

- Kapitel „UML (Unified Modelling Language)”

In diesem Kapitel wird vorerst die geschichtliche Entwicklung der UML beschrieben. Dem folgend, werden (in Anlehnung an den aktuellen UML Standard 1.4) anhand von zahlreichen Abbildungen und Graphiken alle UML Diagrammarten detailliert erklärt.

- Kapitel „UML Werkzeuge“

Anhand des Beispiels „Flughafenleitsystem“ werden drei bestehende UML Werkzeuge evaluiert und abschließend mit einem Schulnotensystem beurteilt. Die zahlreiche Anzahl der sich auf dem Markt befindenden UML Werkzeuge gestaltete die Auswahl sehr schwer: Der ausschlaggebende Grund für die Entscheidung für die UML Werkzeuge Visio, Rational Rose und ArgoUML war die Verschiedenheit aller drei: Visio ein „Massenprodukt“, Rational Rose ein professionelles Werkzeug und ArgoUML eine „Freeware“ Software.

- Kapitel „Anforderung an professionelles UML Werkzeug“

Aufgrund der erworbenen Erkenntnis aus Kapitel UML Werkzeuge wird ein Kriterienkatalog für ein professionelles UML Werkzeug festgelegt resp. definiert. Nicht zu letzt wegen der hohen Inakzeptanz gegenüber solcher Softwareunterstützungswerkzeuge wird neben den funktionalen Anforderungen wie UML Konformität, Darstellung am Bildschirm, Roundtrip Engineering usw. besonders versucht, die Kriterien im Hinblick auf Anwenderfreundlichkeit aufzustellen.

- Kapitel „Zusammenfassung und Ausblick“

Dieses abschließende Kapitel fasst die erworbene Erkenntnis zusammen und gibt Ausblick über mögliche Weiterentwicklungen von UML Werkzeugen.

1.4 Schreibweise und Modellierung der Diagramme

Neben der oben beschriebenen Motivation ist gute Lesbarkeit und – ohne jegliche informatische Grundkenntnis – Verständlichkeit ein wichtiges Ziel dieser Arbeit. Aus diesem Grund wurde versucht, so weit als möglich, Deutsche Begriffe und Erklärungen zu verwenden. Nicht vermeidbare Fachbegriffe wurden ausführlich beschrieben und erklärt.

Um Stärken und Schwächen, aber auch Unterschiede der evaluierten UML Werkzeuge besser zu verdeutlichen, wurde bei allen erstellten Diagrammen in Kapitel UML Werkzeuge besonders darauf geachtet, dass sowohl die Stärken bei der Modellierung dargestellt, als auch festgestellte Mängel bei den Abbildungen von Diagramme nicht ausgebessert wurden.

Außerdem wird aus Gründen der besseren Lesbarkeit grundsätzlich die männliche Form stellvertretend für weibliche und männliche Formen verwendet.

2 Software –Engineering und Modellierung

2.1 Einleitung

Während sich traditionelle naturwissenschaftliche Ingenieursdisziplinen wie Maschinenbau, Elektrotechnik oder Mathematik im Laufe ihrer langen geschichtlichen Entstehung entwickeln haben können, hat das Software – Engineering nur sehr wenig Zeit für ihre Entwicklung beansprucht. Dennoch gibt es heute sehr viele Ansätze, die versuchen, den Prozess des Software – Engineering zu beschreiben. Der Versuch dieser algorithmischen Beschreibung für die Vorgangsweise bei der Softwareentwicklung ist aber keineswegs abgeschlossen. Dies ist vor allem daraus ersichtlich, dass mehr als 30% aller Softwareprojekte vor ihrer Fertigstellung abgebrochen und mehr als 70% der verbleibenden Projekte nicht die gewünschte Funktionalität liefern [vgl. Pete01].

Es stellt sich hier berechtigter Weise die Frage, nach der Existenz eines alles umfassenden „Kochbuches“ für Softwareentwicklung. Leider gibt es dieses nicht. Vielmehr gibt es Ansätze resp. Softwareentwicklungsmodelle, die durch ihrer Stärken und Schwächen ausgezeichnet sind.

Im folgenden Kapitel wird ein Einblick in die geschichtliche Entwicklung des Software – Engineering, Prinzipien und Personen eines Softwareentwicklungsprozesses und Vorgehensmodelle in der Software – Engineering gegeben.

Des Weiteren wird die objektorientierte Softwareentwicklung, im Speziellen mit ihren Phasen Analyse und Entwurf in Bezug auf UML (siehe Kapitel 3), beschrieben. Die Bedeutung dieser Phasen wird von einigen Softwareentwicklern unterschätzt, was umso mehr verwundert, da rund 60% aller Softwareentwicklungsfehler in der Analysephase und ca. 40% in der Entwurfsphase [vgl. Pete01] entstehen.

Zusammenfassend wird noch ein Überblick über Modelle und Modellbildungen in der Informatik und im Speziellen in der Software – Engineering Tätigkeit gegeben.

2.2 Software – Engineering

2.2.1 Historie des Software – Engineering

Eng verbunden mit der Geschichte der Softwareentwicklung ist die Entstehung und Entwicklung der ersten Programmiersprache:

Im Zeitraum von 1942 bis 1945 wurde nicht nur der erste Computer (Z3) gebaut, sondern auch die damit verbundene erste textbasierende „richtige“ Programmiersprache (Plankalkül) durch Konrad Zuse entwickelt. Der heutige Begriff des modernen „Software – Engineering“ (siehe weiter unten) ist allerdings nicht mit der damaligen Bedeutung gleichzusetzen. Während man damals vornehmlich Recheneinheiten codierte, umfasst der heutige Begriff der Softwareentwicklung einen weit größeren Aspekt (siehe Abschnitt 2.2.2, Definition des Begriffs der Softwareentwicklung).

Ein Weiterer Meilenstein in der Softwareentwicklung ist die Entwicklung von imperativen Programmiersprachen in den 60er Jahren (COBOL im kaufmännischen und Fortran im wissenschaftlichen Bereich). Auch die Sprachen Pascal, C, Simula und ADA entstanden zu dieser Zeit.

Die Weiterentwicklung dieser imperativen Sprachen in den 70er Jahren führte schließlich zu den ersten objektorientierten (OO) Ansätze. Die Verwendung von Klassen und Objekte wurde mit der ersten objektorientierten Programmiersprachen (OOP) Simula und Smalltalk eingeführt. Sogar die heute bekannten OOP wie C++ und Java lehnen sich stark an Smalltalk an [vgl. Pich02].

Als Geburtsstunde des Software – Engineering gilt allgemein die NATO „Software – Engineering“ - Konferenz in Garmisch. 1968 trafen unter der NATO – Initiative Experten aus den Bereichen Militär, Universitäten und anderen Organisationen zusammen, um den aktuellen Forschungs – und Entwicklungsstand im Softwarebereich zu erarbeiten und Lösungen für eine strukturierte Vorgehensweise bei der Entwicklung von Software darzulegen. Aufgrund der immerzu steigenden Kosten und Dauer von Softwareprojekten, der hohen Anzahl von fehlerhaften Softwaresystemen und vor allem der Zunahme von Software im militärischen Bereich, führte dazu, dass man zum ersten Mal von der sog. „Softwarekrise“ sprach [Thei02]. Es wurde versucht, eine allgemein gültige Richtlinie zu definieren, die solche Fehler erst gar nicht entstehen lassen. Dabei wurde erkannt, dass ein Umdenkprozess von der traditionellen Softwareentwicklung zu planenden Ingenieurstätigkeit „Software – Engineering“ stattfinden muss.

„Die ersten Rechenanlagen wurden vorwiegend im Bereich der Wissenschaft und Technik eingesetzt [...] Die einzigen Probleme waren, Korrektheit und Effizienz zu gewährleisten. Die zu lösenden Aufgaben waren im Vergleich mit heute verhältnismäßig einfach, und deshalb waren die Programme auch relativ klein. Die Anzahl der Programmierfehler war gering und wurde erst zum wirklichen Problem, als man daranging, Programmiersysteme zur Lösung komplexer wissenschaftlich – technischer und kommerzieller Aufgaben einzusetzen [...] Neben Korrektheit und Effizienz wurden die Meisterung der Komplexität durch Zerlegung einer Aufgabe in Teilaufgaben, die Spezifikation der Schnittstellen, Sicherheit und Zuverlässigkeit, Flexibilität, Dokumentation, Wartbarkeit und die Projektorganisation zu den Hauptproblemen bei der Herstellung großer Programmsysteme. Dies führte in einem solchen Maße zu Schwierigkeiten beim Entwurf und der Produktion von Software, dass man im Jahre 1965 von der Softwarekrise zu sprechen begann“ [Pomb87, S. 1]

Auf der darauf folgenden Software – Engineering Konferenz der NATO 1969 in Rom begann man schließlich Programmiersprachen, Planung und Vorgehensweisen bei der Erstellung von Software zu vereinheitlichen. Auch die Annerkennung von Software – Engineering als eine ingenieurmäßige Tätigkeit erfolgte auf dieser Konferenz.

Seit diesem Zeitpunkt sind viele Softwareentwicklungsmodelle entstanden, die oben zitierten Aspekte wie Unterteilung einer komplexen Aufgabe in mehrer Teilaufgaben, Spezifikation, Analyse und Entwurf, versuchen zu beschreiben.

2.2.2 Definition des Begriffs „Software – Engineering“

Der Begriff „Software – Engineering“ bedeutet „Software – Technik“ und umfasst Aspekte von

- Entwicklung
- Pflege und
- Einsatz

von qualitativ hochwertiger Software unter Einsatz von

- wissenschaftlichen Methoden
- wirtschaftlichen Prinzipien
- geplanten Vorgehensmodellen
- Werkzeugen und
- quantifizierbaren Zielen! [vgl. Schr02]

Die Bedeutung und Größe der Software – Industrie hat in den letzten 30 Jahren enorm zugenommen. So schätzt man heute, dass weltweit ca. 2850 Milliarden US$ in der Informationstechnik umgesetzt werden [Quelle: G. Koch, European IT Conference, Brüssel, 1994]. Die Größe dieser Softwareprojekte lässt sich nicht mit kleineren Applikationen vergleichen. Vielmehr handelt es sich hierbei um viele Millionen Codezeilen. Eine vergleichsmäßige Dimension wäre z.B. die Implementation des Bordcomputers der Ariane – 5: Dieses Beispiel der Ariane – 5 soll außerdem aufzeigen, zu welchen Katastrophen falsch geplante und schließlich nicht korrekt implementierte Software führen kann:

„On the June4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then it began to vear off course. At the direction of the Ariane ground controller, the rocket was destroyed by remote control […] total cost of the disaster was $500 million” [Pfle98, S. 37].

Ursache dieser Katastrophe war, dass die Software teilweise von der Ariane – 4 übernommen wurde, sodass der Bordcomputer mit den technischen Daten der Ariane – 4 rechnete. Bei der Berechnung der Flugbahndaten kam es zu einem Überlauf bei der Real – Integer – Konvertierung, was schlussendlich den Absturz bewirkte.

2.3 Prinzipien des Software Engineering

2.3.1 Vorgehensmodelle in der Softwareentwicklung

Es gibt zahlreiche Vorgehensmodelle in der Softwareentwicklung. Einige davon sind:

Wasserfallmodell

V-Modell

W-Modell

Prototypenmodell

Spiralmodell

Springbrunnenmodell

Rational Unified Process (RUP)

Extreme Programming

EXXcellent Process

Im Folgenden wird das Wasserfallmodell, Spiralmodell und Rational Unified Process (RUP) detaillierter beschrieben:

- Wasserfallmodell:

Zählt mit dem Spiralmodell zu den ersten Vorgehensmodellen in der Softwareentwicklung.

Man teilt beim Wasserfallmodell den Softwareentwicklungsprozess in Phasen ein und versuchte, streng sequentiell alle Phasen zu durchlaufen, bis man schließlich beim Ziel anlangt. Die fünf Phasen des Wasserfallmodells sind: Systemspezifikation, Systementwurf, Systemimplementierung, Systemintegration und Systemtest. Von einer Phase zur anderen gelangt man erst, sobald die gerade bearbeitete Phase abgeschlossen ist. Abgeschlossen ist eine Phase erst dann, wenn die Review der Phase positiv verläuft, d.h. entschieden wird, dass die Phase fertig gestellt ist. Wird in der Review entschieden, dass Fehler beim bisherigen Entwicklungstand gemacht wurden, werden diese Fehler in dieser, oder früheren Phasen ausgebessert.

Die sequentielle Abarbeitung der Phasen ist auch schon der größte Kritikpunkt dieses Vorgehensmodells, denn oft und gerade in der Softwareentwicklung ist es notwendig, dass die Möglichkeit besteht, schon während einer Phase zur Vorgängerphase „zurückzukehren“ und nicht erst nach Abschluss dieser. Dies ist nicht zuletzt darum erforderlich, da z.B. in der Analysephase Kunden selten genau wissen, was sie wollen (Nach dem Motto: „Ich kann dir jetzt nicht sagen, was ich will, aber ich weiß es, wenn ich es sehe“) [vgl. Blue03].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Wasserfallmodell [nach Page01, Wasserfallmodell]

In Abbildung 1 werden die vier Phasen des Wasserfallmodells dargestellt: Der Pfeil auf der rechten Seite symbolisiert die einzige mögliche Richtung der Abarbeitung. Ein Phasenübergang erfolgt erst dann, wenn die bearbeitete Phase abgeschlossen ist.

Ein Vorgehensmodell sollte aber flexibel sein und zugleich eine „Rechenvorschrift“ vorschreiben. Diese Schwierige Synthese wurde versucht, mit dem Spiralmodell zu vollziehen.

- Spiralmodell:

Wurde von Boehm 1988 entwickelt. Der Grundgedanke des Spiralmodells ist, dass die Spirale, und somit die einzelnen Phasen des Wasserfallmodells, vier Mal durchlaufen wird. Bei jedem Durchlauf wird darauf geachtet, dass die Ziele (wie Funktionalität), Alternativen (wie Entwurf) und Einschränkungen hinsichtlich der Alternativen (wie Kosten) neu festgelegt bzw. über Einhaltung überprüft werden. Ergibt die Risikoanalyse keine Bedenken, so wird nach der traditionellen Wasserfallmethode weitergemacht.

Die vier Phasen [nach Zuse01] und deren wichtigste Tätigkeiten sind:

1. Zielbestimmung

Jede Phase beginnt mit der Bestimmung der genauen Ziele in der sich gerade befindenden Phase. Es wird außerdem die Einhaltung des Zeitplans überprüft.

2. Risikoanalyse

Die in der vorherigen Phase bestimmten Ziele werden einer Risikoanalyse unterworfen. Dabei sollen eventuell festgestellte Risiken beseitigt resp. gelöst werden.

3. Arbeitsschritte durchführen

In dieser Phase erfolgt die Erstellung der für diese Phase vorgesehen Produkte.

4. Nächste Phase planen

Anhand der durchgeführten Reviews werden die Phasen bei einem neuerlichen Durchgang in der Spirale geplant.

In Abbildung 2 dargestelltes Spiralmodell zeigt alle vier Phasen, die spiralartig, sich wiederholend durchlaufen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Spiralmodell [vgl. Kahl01]

Sowohl die Wasserfallmethode, als auch das Spiralmodell haben den Nachteil, dass sie funktionsorientierte Ansätze sind, d.h. gibt es auch noch so kleine Änderung während bzw. nach der Fertigstellung der Software, so sind die Modelle meistens unbrauchbar und die gesamte Modellierung beginnt von vorne.

Ziel der neuen, in den 80er Jahren entwickelten Vorgehensmodelle war es, Modelle zu entwickeln, die ohne Änderung der Modelle selbst, sich leicht an Änderungen in der Entwicklungsphase anpassen:

- Objektorientierte Modelle:

Die ersten objektorientierten Modelle entstanden Ende der 80er Jahre. Die wohl am bekanntesten sind Rational Unified Process (RUP) und Unified Software Development Process.

Alle objektorientierten Modelle haben gemeinsam, dass das zu realisierende System iterativ und inkrementell entworfen wird. „Anstatt nun das System ‚wasserfallmäßig’ als Ganzes in Phasen zu realisieren, bietet sich an, es schrittweise (inkrementell) in Teilen zu entwickeln, mit einem ständigen Zuwachs an Funktionalität“. [Müller99]

In anderen Worten: das Gesamtsystem wird in Module (Objekte) unterteilt, die miteinander kommunizieren. Die Kommunikation bzw. die Zusammenarbeit aller Objekte (Module) bildet das Gesamtsystem. Die traditionellen Phasen der Wasserfallmethode sind nach wie vor enthalten, der große Unterschied ist allerdings der, dass es nicht nur eine sequentielle Abarbeitung der Phasen für das gesamte Projekt gibt, sondern das nun jede Teileinheit die fünf Phasen besitzt. Diese Teileinheiten des gesamten Softwaresystems bilden sozusagen ein Miniprojekt.

Diese iterative Entwicklung bringt vor allem die Vorteile mit sich, dass nun einerseits Risiken schon früh erkannt, ausgebessert und Änderungen besser in den Entwicklungsprozess einfließen (da Kunde schon früh mit dem System vertraut wird: “Look and Feel“) und andererseits die Planung für den Entwicklungsprozess stabiler wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Unified Process [vgl. Jaco99]

Das in Abbildung 3 dargestellte Unified Process wurde von der Firma Rational Software entwickelt. Auf der linken Hälfte der Abbildung befinden sich die englischen Bezeichnungen für die bereits bekannten fünf Projektphasen (Requirements = Spezifikation, Analysis = Analyse, Design = Entwurf, Implementation = Implementierung und Test). Neu hinzugekommen sind folgende vier iterative Schritte:

1. Inception

Das erste Ziel dieser Phase ist, eine Analyse im Rahmen des Projektmanagement zu tätigen, d.h. hier werden Schätzungen in den Bereichen Zeit, Risiko und Kosten, der zu erstellenden Software, durchgeführt.

Des Weiteren werden alle Anwendungsfälle (siehe Kapitel 3) und ein Prototyp erstellt.

2. Elaboration

In dieser Phase werden alle funktionellen und nicht funktionellen Anforderungen erarbeitet. Die in der Inception Phase aufgestellten Schätzungen über Zeit, Risiko und Kosten werden mit einem detaillierten Projektplan vervollständigt. Auch die Anwendungsfälle werden auf Vollständigkeit analysiert und die Basisarchitektur des Systems festgestellt. Das Klassendiagramm (siehe Kapitel 3) und Datenmodell werden modelliert.

3. Construction

In dieser Phase erfolgt die Implementierung des Systems. Qualitätssicherung anhand von Tests (siehe weiter unten) wird auch in dieser Phase vorgenommen.

Das wesentliche Ziel dieser Phase ist es, eine ausführbare, testbare Version der Software zu erstellen.

4. Transition

Ist die Endphase. In dieser Phase wird das Produkt dem Auftraggeber übergeben. Optional erfolgt neben der Übergabe auch eine Schulung, die den Endanwender in die Handhabung der neu erstellten Software einführen soll.

Der größte Unterschied vom Unified Process gegenüber bisher beschriebenen Vorgehensmodelle ist allerdings, dass keine strikte Trennung der einzelnen Phasen vorgesehen ist, sondern die Phasen überlappend und auch parallel ausgeführt werden können.

2.3.2 Die Analyse – und Entwurfsphase in der Objektorientierung

Wie bereits erwähnt, bestand das Entwickeln von Software zurzeit von Konrad Zuse vornehmlich aus dem Kodieren von Recheneinheiten. Eine detaillierte Planung war damals nicht notwendig. Heutzutage hingegen ist wegen der Vernetzung und Verbreitung von Computern die Anforderung an und die Komplexität von Software gestiegen. Diese hohen Erwartungen und nicht zuletzt die hohen Entwicklungskosten sind verantwortlich dafür, dass ohne sorgfältige Planung, Projekte entsprechender Größenordnung nicht mehr zu realisieren wären [vgl. Perd94].

Eine systematische Vorgehensweise ist also unumgänglich. Für eine sinnvolle Gliederung der objektorientierten Planung sind für jeden iterativen Schritt (siehe Abschnitt 2.3.1, Unified Process) die Phasen Analyse, Entwurf, Implementierung und Validierung (bzw. Test) vorgesehen. Während in der Implementierungsphase die in der Entwurfsphase entworfenen Lösungen implementiert werden, wird in der Validierungsphase anhand von formalen Methoden und Test das Ergebnis sowohl der Implementierungsphase als auch der Entwurfsphase getestet.

Im folgenden Abschnitt wird gesondert die Analyse – bzw. Entwurfsphase erläutert:

- Die Analysephase

Der erste Schritt in der Analysephase besteht darin, in Gesprächen mit dem Kunden die Anforderungen an die zu realisierende Software zu definieren. Bei dieser Definition des zukünftigen Produkts ist darauf zu achten, dass eventuell vorhandene Kommunikationsprobleme zwischen Auftraggeber und Analytiker beseitigt werden, d.h. der Analytiker muss in der Lage sein, den Kunden auch richtig zu verstehen. Das Ziel dieser Kundengespräche soll sein, dass der Analytiker die wichtigsten Klassen und die Zusammenhänge dieser Klassen findet. Es wird in dieser Phase allerdings nur aus der Anwendersicht modelliert, d.h. der Analytiker beschreibt zusammen mit dem Auftraggeber das System aus einer „Außensicht“. Auf technische Details wird in diesem Stadium der Softwareentwicklung keine Rücksicht genommen.

Anhand des erstellten Analysedokuments wird anschließenden das sog. Analysemodell entworfen (für das Analysemodell sind UML Diagramme vorgesehen, die in Kapitel 3 ausführlich beschrieben werden). Beim Analysemodell werden die statische und dynamische Struktur beschrieben:

Für die visuelle Modellierung der statischen Struktur bieten sich z.B. UML –

Klassendiagramme an und für die dynamische Struktur sind UML – Anwendungsfälle geeignet.

Die Dokumentation während dieser Phase ist für den weiteren Verlauf des Projekts immens an Bedeutung, denn schließlich ist das Analysedokument die Grundlage für den positiven Fortgang der folgenden Softwareentwicklungsphasen. Das Analysedokument wird auch als Übereinkunft mit dem Auftraggeber verwendet.

Wie bereits erwähnt, gibt es kein alles umfassendes „Kochbuch“, an welches man sich bei der Planung von Softwareprojekten halten könnte. Darum ist es schwer, eine klare Definition für das Ende der Analysephase zu finden. Wichtig ist, dass die Phasen keineswegs als streng definierte Arbeitsschritte anzusehen sind, im Gegenteil, es kommt sogar oft vor, dass sich Phasen überlappen oder parallel ausgeführt werden. Falls dennoch nach einem klaren Ende der Analysephase gesucht wird, könnte man die Vertragsunterzeichnung, d.h. die Übereinkunft und Unterzeichnung des Analysedokuments durch Projektleiter und Auftraggeber, als solches ansehen.

Folgende Dokumente sind in der Analysephase zu erstellen: [vgl. Riec02, S. 147]

1. Textliche Beschreibung der zu entwickelnden Software:

Zu Beginn wird in wenigen Worten die Hauptaufgabe des zu realisierenden Systems beschrieben. Auch die „Nichtanforderungen“ (=was nicht zu machen ist) werden hier schon festgehalten.

2. Ermittlung der Anwendungsfälle:

(siehe Kapitel 3, Anwendungsfalldiagramme)

3. Festlegung der Anforderung:

Nachdem alle Anwendungsfälle erstellt sind, werden die Anforderungen an das zukünftige System sichtbar. Nun gilt es, diese Anforderungen zu formulieren. Diese Formulierung der Anforderungen wird auch Requirements Engineering genannt, deren genaue Beschreibung in [H.Partsch98] nachzulesen ist.

Das Ergebnis der Anforderungsanalyse ist das sog. Pflichtenheft. Es dient hauptsächlich dafür, den Projektmitarbeitern eine Richtlinie für die zu erstellende Software zu geben.

4. Entwicklung des Klassenmodells:

(siehe Kapitel 3, Klassendiagramme)

Zusammenfassend lässt sich festhalten, dass in der Analysephase das zu entwickelnde System grob beschrieben wird. Die erstellten Dokumente konzentrieren sich ausschließlich auf die externe Sicht, technische Details werden erst in der Entwurfsphase modelliert.

- Die Entwurfsphase

In der Entwurfsphase gilt es nun, das Analysemodell zu verfeinern. Diese technisch detaillierte Beschreibung besteht darin, Attribute und Methoden für alle Klassen zu spezifizieren und Abläufe im System genau zu beschrieben. (siehe Kapitel 3, Klassen – und Verhaltensdiagramme). Da der Entwurf die Grundlage der folgenden Implementierung ist, sollte auch bei der detaillierten Beschreibung resp. Dokumentation nicht „gespart“ werden. Es gilt folgende Regel: „Je detaillierter technische Details in der Entwurfsphase spezifiziert worden sind, desto schneller erfolgt die Implementierung!“

„Bei der Auswahl einer Entwicklungsumgebung kann man unter zwei Möglichkeiten wählen: Entweder einigt man sich unabhängig vom Projekt auf eine Entwicklungsumgebung, oder man sucht für die Implementierung die Geeignetste“ [vgl. Zuse01, S. 122]. Die zweite Variante ist sicherlich die Schwierigere, da sich die Auswahl der Projektmitarbeiter resp. Programmierer nach der Entwicklungsumgebung richtet und somit das Finden von qualifiziertem Personal erschwert wird. Entscheidet man sich für die erste Variante, muss darauf geachtet werden, dass die erstelle Software und Anwenderarchitektur nicht zu sehr an die Entwicklungsumgebung gebunden ist. Auf welche Entwicklungsumgebung man sich schlussendlich entscheidet, obliegt dem technischen Architekten (näheres dazu siehe Abschnitt 2.3.3, Personen in Softwareprojekten). Als eine Entscheidungshilfe können bereits existierende Lösungen dienen. So sollten bei der Festlegung folgende Aspekte eine Rolle spielen: „Sind grundlegende Klassen, wie Listen, Bäume auf Zielplattformen bereits vorhanden, sind diese unter anderem in Standardbibliotheken zu finden usw.“ [vgl. Riec02, S. 154].

Die größte Herausforderung der Entwurfsphase ist jedoch, das „altern“ und somit die Neugestaltung der Software so lang wie möglich hinauszuzögern, d.h. es sollte in der Entwurfsphase auf die Aspekte wie einfache Erweiterbarkeit, modularer Aufbau usw. nicht vergessen werden [vgl. Riec02, S. 154].

Folgende Dokumente und Beschreibungen sind in der Entwurfsphase zu erstellen: [vgl. Riec02, S. 155]

1. Verfeinerung des Analysemodells

In der Entwurfsphase wird so genau wie möglich das grob erstellte Klassenmodell der Analysephase technisch beschreiben, Es dürfen keinerlei Frage bzw. Unklarheiten für die Implementierung offen bleiben.

Nachdem alle Klassen mit ihren Attributen und Methoden spezifiziert worden sind, wird versucht, zusammengehörige Klassen in Komponenten zusammenzufassen. Dabei ist zu beachten, dass Komponenten resp. das gesamte Klassenmodell modular aufgebaut ist. D.h. es sollte zu jeder Zeit möglich sein, beliebige Klassen auszutauschen. Aus diesem Grund sind genau definierte Schnittstellen notwendig. Diese Schnittstellen(klassen) sind schon in der Entwurfsphase und nicht erst in während der Implementierung festzulegen.

2. Festlegung der Anwenderarchitektur

Hat man alle zusammengehörigen Klassen zu unabhängigen Komponenten zusammengefasst, wird die Architektur des zu erstellenden Systems beschrieben. Die Schwierigkeit bei der Spezifikation der Anwenderarchitektur besteht darin, sich auf eine am besten geeignetste Architektur zu einigen. Dabei ist es hilfreich, bereits existierende, ähnliche Systeme zu vergleichen und diese für das neu zu erstellende zu adaptieren. Je nach Größe und Komplexität des Softwaresystems, wird zwischen folgenden Systemen unterschieden:

Stand – Alone – System (=Ein – Platz – Rechner),

Verteilte System (=mehrere Rechner sind mit einem Netzwerk verbunden)

und

zwei resp. drei – Schichten – Architektur (=Trennung der Repräsentationsschicht = GUI = Graphical User Interface von der Anwendungsschicht = Applikation und der Datenschicht =Datenbank).

Eine UML – konforme Darstellung für alle Architekturformen ist mit einem Einsatz – bzw. Verteilungsdiagramm (siehe Kapitel 3) gegeben.

2.3.3 Personen in Softwareprojekten

Grundsätzlich kann man die in einem Softwareprojekt beteiligten Personen in zwei Klassen einteilen, nämlich auf einer Seite den Auftraggeber und ihm gegenüber das Softwareentwicklungsteam. Je nach Größe des Projektes besteht das Entwicklungsteam aus mehreren Gruppen von Personen:

- Projektleiter

Die Hauptaufgabe eines Projektleiters ist die Koordination der Mitarbeiter und Ressourcen, die für eine erfolgreiche Durchführung des Projekts notwendig sind. Er ist auch die erste Ansprechperson für den Auftraggeber. „Der Projektleiter trägt außerdem die wirtschaftliche und technische Verantwortung bei der Projektdurchführung [...]“ [Zuse01, S. 36].

In der Regel erfolgt auch der Erstkontakt mit dem Auftraggeber über den Projektleiter. Bei diesem Kontakt wird versucht, die Anforderungen der zu erstellenden Software aufzustellen. Anhand dieses sog. Anforderungskatalogs werden von ihm die benötigten und bestqualifizierten Mitarbeiter und Ressourcen geplant.

Während eines Projekts besitzt ein Projektleiter außerdem die Aufgabe, den gesamten Prozess der Softwareentwicklung zu „reviewen“, d.h. alle Codeteile, Programmstücke, Berichte und Dokumentationen werden von ihm in regelmäßigen Abständen auf Konsistenz überprüft.

- Technischer Architekt

Die Hauptaufgabe des technischen Architekten ist es, gemeinsam mit dem Projektleiter, die technische Umsetzung (Implementierung) des Anforderungskatalogs zu verantworten. Zu Projektbeginn zählt auch das Erstellen der Spezifikation zu seinen Aufgaben. Aus diesem Grund ist ein hohes technisches Wissen und analytisches Denkvermögen Voraussetzung. Während des Projekts ist er die zentrale Person und Ansprechpartner für alle technischen Fragen. Besonders Schwierigkeiten und Fragen der Programmierer werden von ihm geklärt. Da die hohe fachliche Kompetenz eines technischen Architekten nicht leicht zu kompensieren ist, gehören das (Mit)Codieren und die Unterstützung der Programmierer auch zu den erweiterten Aufgaben eines technischen Architekten.

- Programmierer

Diese Personen implementieren die Spezifikation und sind direkt dem technischen Architekten unterstellt. Hauptaufgabe der Programmierer ist es, anhand der Spezifikation (=Anforderungs – und Analysemodell) ein fehlerfreies Softwaresystem zu codieren.

- Tester

Testen die erstellte Software sowohl auf syntaktische & semantische Fehler im Programmcode, als auch auf Konsistenz der Software mit der Spezifikation. Tester sind eigentlich keine unmittelbaren Programmierer, d.h. es ist sinnvoll, den Quellcode des jeweils anderen zu testen als den eigenen. Bei großen Projekten können Tester auch extern beauftragte Personen sein.

Je nachdem, in welchem Stadium man sich befindet, gibt es verschiedene Testmöglichkeiten. Grundsätzlich kann zwischen sog. Black – und Whitebox Testing unterschieden werden (näheres dazu siehe Abschnitt 2.3.4).

- Extern Beauftragte

Je nach Größe und Dimension der zu erstellenden Software kann es auch notwendig sein, interdisziplinäre Fachkräfte zu beauftragen. Folgende zwei Szenarien wären vorstellbar:

Ein international tätiger Konzern beauftragt ein Softwareentwicklungsteam zur Realisierung eines neuen Webshops. Da zukünftige Kunden des Konzerns aus verschiedenen Ländern und somit aus verschiedenen Gesetzgebungen kommen, ist es bei der Modellierung der Software notwendig, alle gültigen Gesetzte der einzelnen Länder zu berücksichtigen. Z.B. in einem Land ist für im Internet getätigte Buchungen eine „14 – Tage“ Kaufvertragsrücktrittsrecht vorhanden, im anderen eine „einmonatige“. Diese verschiedenen Gesetzgebungen beeinflussen natürlich auch die Implementierung der Applikation. Darum muss vor Projektbeginn ein Berater (in diesem Fall ein Rechtsanwalt mit Spezialisierung auf Internet – und Internationales Recht) beigezogen werden.

Oft werden bei großen Projekten auch Psychologen, welche die Anwenderakzeptanz bzw. Anwenderfreundlichkeit eines Prototypen untersuchen, zur Unterstützung herbeigezogen.

2.3.4 Dokumente und Produkte eines Softwareprojektes

Neben dem Softwaresystem, das dem Kunden ausgeliefert wird, entstehen im Laufe eines Softwareprojekts eine Reihe von zusätzlichen Produkten. Die Anzahl und Umfang dieser Produkte hängt von der Größe der zu erstellenden Software ab.

Produkte eines Softwareprojekts lassen sich in zwei Bereiche einteilten, nämlich in Dokumente und technische Produkte. Während technische Produkte, wie die fertig gestellte Software, weitgehend bekannt sind, wird bei der Erstellung der dazugehörigen Dokumentation oft „gespart“. Speziell die intern in einer Softwaregruppe erstellten und verwendeten Dokumente dienen zu einer laufenden Qualitätssicherung resp. Kontrolle des Projektfortgangs. Dokumente, die an den Auftraggeber ausgeliefert werden, sollen ihn bei der Benutzung des ausgelieferten Softwaresystems behilflich sein und Missverständnisse bezüglich Funktionalität vorbeugen.

Im Folgenden wird eine Liste von zu erstellenden Dokumenten und Diagrammen gegeben, die im Laufe einer Softwareentwicklung anfallen.

1. Anwendungsfalldiagramm

(siehe Kapitel 3, Anwendungsfalldiagramme)

2. Anwendungsfallbeschreibung

(siehe Kapitel 3, Anwendungsfallbeschreibung)

3. Projektplan

Nach den ersten Gesprächen zwischen Auftragsgeber und Projektleitung wird aufgrund der Anforderungsanalyse eine grobe Einschätzung der Dauer des Projekts vorgenommen. Die tatsächliche Dauer eines Projekts lässt sich nur sehr schwer einschätzen. Leider gibt es keinen alles umfassenden Leitfaden für die Berechnung der Projektdauer, vielmehr beruht die Schätzung auf Erfahrungswerten der Projektleitung.

Projektpläne werden gewöhnlich als Balkendiagramme, welche die Dauer der einzelnen Phasen repräsentieren, mit den dazugehörigen verantwortlichen Personen dargestellt. Da sich die tatsächliche Projektdauer nur schwer abschätzen lässt, werden in Projektplänen starr definierte, fix einzuhaltende Termine, sog. Meilensteine definiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Projektplan

4. Systemschnittstellenbeschreibung

In der Systemschnittstellenbeschreibung werden alle Schnittstellen zum Fremdsystem definiert und beschrieben. Dabei ist zu beachten, dass es sich hier um eine Anbindung zu einem Fremdsystem handelt und somit eine mögliche Fehlerquelle darstellt. Aus diesem Grund werden in diesem Dokument alle Methodenaufrufe (Parameter, Rückgabewerte usw.), mögliche Fehlerquellen etc. beschrieben.

Üblicherweise wird die Systemschnittstellenbeschreibung tabellarisch dargestellt, in der ein Titel, eine Kurzbeschreibung, eine Liste aller Methoden und möglichen Fehlerquellen vorhanden sind.

Eine Systemschnittstellenbeschreibung für einen E-Mail-Server könnte nach [Zuse01, S. 101, Abbildung 4.16] wie folgt dargestellt werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 Systemschnittstellenbeschreibung

5. Systemarchitekturbeschreibung

Die Systemarchitekturbeschreibung beschreibt die Teile, aus (auf) denen die zu realisierende Software „läuft“. Je nach Komplexität und Anforderung kann zwischen sog. „Verteilten Systemen“ oder „Stand-Alone Systemen“ unterschiedenen werden (siehe auch Abschnitt 2.3.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Systemarchitektur

Abbildung 5 zeigt eine Cliparts Darstellung von einer möglichen Systemarchitektur: Die Datenbank verbindet sowohl alle Rechner untereinander als auch alle Rechner mit dem Drucker resp. Plotter.

6. Integrationsplan

Hier wird die zeitliche Dauer festgehalten, die für die Zusammensetzung der stückweise programmierten Systemteile zu einem Gesamtsystem vorgesehen ist. Bestens geeignet wäre ein Balkendiagramm, welches nicht nur den Zeitpunkt und Dauer der Integration festhält, sondern auch jeweils den Verantwortlichen für eine Teilintegration (siehe Projektplan).

7. Klassendiagramm

(siehe Kapitel 3, Klassendiagramm)

8. Testfälle

Es wird zwischen Black – und Whiteboxtestfällen unterschieden.

Blackboxtestverfahren:

Mit Black Box Tests (kurz BB) werden Anwendungsfälle getestet. Da Anwendungsfälle bereits in der Analysephase vollständig modelliert werden, kann schon sehr früh in der Softwareentwicklungsphase getestet werden.

„BB dienen nicht zur exakten Lokalisierung des falsch funktionierenden Codes, sondern zur grundsätzlichen Überprüfung der korrekten Funktionsweise eines Systemteils. Werden Fehler gefunden, muss die Quelle des Fehlers mit anderen Mitteln (z.B. White – Box – Test oder Debug – Tools) gesucht werden“ [Zuse01, S. 198].

Mit BB ist in einem vertretbaren Zeitaufwand unmöglich, alle Kombinationen von Eingabemöglichkeiten zu testen. Es wird vielmehr versucht, mögliche Eingaben repräsentativ zu Klassen zusammenzufassen. Diese Klassen werden Äquivalenzklassen genannt. Üblicherweise werden drei Äquivalenzklassen (Normal –, Sonder – und Fehlerfall) tabellarisch aufgelistet. Außerdem besitzt jeder Testfall eine eindeutige fortlaufende Nummer, kurze prägnante wörtliche Beschreibung, ein erwartetes Ergebnis (ist das Ergebnis, das nach einer bestimmten Eingabe vom System erwartet wird) und eine beispielhafte Eingabe (ist die Eingabe, die vom Anwender eingegeben wurde).

Ein BB Testfall für ein Internet – Eingabeformular könnte wie folgt dargestellt werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2 Black Box Testfall

Whiteboxtestverfahren:

Mit White Box Test (kurz WB) wird der Sourcecode getestet. Voraussetzung dafür ist natürlich, dass der Sourcecode bereits existiert. Dementsprechend werden WB Test während bzw. nach der Implementierungsphase durchgeführt.

Eine geeignete Vorgehensweise für WB Tests ist zunächst die Modellierung eines Kontrollflussdiagramms, das die Verzweigung (Methodenaufrufe, if .. then – Anweisungen, case – Schleifen usw.) innerhalb eines Codestückes graphisch modelliert. Anschließend wird der zu testende Code mit einem speziellen Testtreiber getestet. Je nach Programmiersprache können auch bereits existierende Tools (wie z.B. für Java das J-Unit Tool) verwendet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Kontrollflussdiagramm (if .. then Anweisung)

Beispiel für ein WB Test [Zuse01, S. 205, Listing 7.1] :

PROCEDURE Sitzplan;

Abbildung in dieser Leseprobe nicht enthalten

9. Anwenderhandbuch

Der Umfang eines Anwenderhandbuchs hängt von der Größe und Komplexität der erstellten Software ab. Es sollte aber dennoch bei noch so vermeidlich kleinen Projekten nicht auf das Anwenderhandbuch verzichtet werden. Schließlich ist dieses (neben der Online Hilfe) die einzige Informationsquelle für den Endanwender.

Bevor ein Anwenderhandbuch erstellt wird, muss klargestellt werden, von welcher Benutzergruppe das Handbuch benutzt werden soll. Sind es unerfahrene Anwender, so sollte man bei der Gliederung des Handbuchs eher die sog. produktorientierte Struktur wählen. Bei der produktorientierten Struktur werden alle Funktionen Schritt für Schritt beschrieben. Um alle Schritte für den Endanwender auch besser nachvollziehbar zu machen, werden Screenshots eingefügt.

Um das Programm warten zu können, benötigen erfahrene Benutzer (wie z.B. EDV Beauftragte einer Firma) hauptsächlich Informationen über „Arbeitsweise“, Algorithmus, Codekommentierung usw. der gelieferten Software.

Vorstellbar wäre ein Anwenderhandbuch, das sowohl die Bedürfnisse des unerfahrenen als auch des erfahrenen Benutzers abdeckt: Im vorderen Teil eines Anwenderhandbuchs befindet sich z.B. die „Schritt für Schritt“ Beschreibung der Funktionen und, abgegrenzt von diesem, in einem eigenen Kapitel die technische Beschreibung für das EDV Personal.

Sprache und Schreibweise eines Anwenderhandbuchs richtet sich natürlich dem Zielpublikum.

10. Online Hilfe

Die zweite bereits erwähnte Informationsquelle für Endanwender ist die Online Hilfe. Die Vorteile einer Online Hilfe gegenüber dem Anwenderhandbuch sind die, dass sie schneller verfügbar ist, im normal Fall eine automatisierte Suchfunktion hat, schneller zu aktualisieren ist und vor allem die Interaktivität zwischen Anwender und Online Hilfe gegeben ist. Dem gegenüber stehen allerdings die Nachteile wie, das Lesen am Bildschirm ist anstrengender und langsamer, die Bedienung für unerfahrene Anwender schwerer und die Implementierung solcher interaktiver Systeme meist mit einem hohen Aufwand verbunden. [vgl. Zuse01, S234, Kapitel: 8.3.2 Online Hilfe).

Die Implementierung einer Online Hilfe erfolgt üblicherweise als Html – oder Windows Hilfedateien. Manchmal kommt es vor, dass „normale“ Textdatei (*.pdf oder *.doc) verwendet werden.

2.4 Modelle des Software Engineering

2.4.1 Modellierung in der Informatik

Modellierung und Modelle sind ein grundlegendes Konzept der Informatik. Mit Modellen wird versucht, die reale Welt anhand von eingeschränkten Möglichkeiten abzubilden. Diese Abbildung kann nur dann erfolgen, wenn bei der Modellierung bewusst auf Genauigkeit resp. Vollständigkeit verzichtet wird. Grundsätzliche Techniken für eine sinnvolle und aussagekräftige Modellierung sind Abstraktion und Strukturierung. Es wird versucht, gleiche (oder ähnliche) Elemente zusammenzufassen (Strukturierung) und auf einen höheren Grad zu abstrahieren. Diese Abstraktion ist Voraussetzung dafür, Schlüsse bzw. Problemlösungen aus erstellten Modellen zu erlauben.

„Zur adäquaten Nutzung informationstechnischer Werkzeuge ist es notwendig, stets die Reduktion der Realität durch Modellbildung und Abstraktion zu verdeutlichen. Denn jeder, der Informationstechnik anwendet, muss wissen, dass er sich mit einer Modellwelt auseinandersetzt, bzw. seine Realität durch andere Menschen modelliert worden ist. Gleichzeitig muss diese Erkenntnis auch dazu führen, dass die Modellwelt, mit der sich Anwender, Nutzer und Konstrukteure auseinandersetzen, niemals zu neuen Realität wird“ [Koer93].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Modellbildung

Zusammenfassend ist festzustellen, dass Modelle nie die gesamte reale Welt repräsentieren. Informationstechnische Modelle nehmen, der Lösbarkeit von komplexen Zusammenhängen wegen, bewusst Ungenauigkeit in Kauf.

„Der Vorgang Softwareentwicklung ist der Weg (Prozess), der von einer Problemstellung zu einem fertigen Programm führt“ [vgl. Riec02].

Wie bereits erwähnt, erlauben Modelle und Modellbildungen in der Informatik komplexe Zusammenhänge zu erkennen, zu verstehen und zu lösen. Es wird zwischen zwei Arten von Modellen unterscheiden: einerseits das statische Modell, welches die statische Beziehung zwischen Elementen beschreibt und andererseits das dynamische Modell, welches die sich ändernde, dynamische Beziehung zwischen Elementen darstellt. Des Weiteren kann man zwischen Technischen, Semantischen und Graphischen Modellen in der Informatik unterscheiden. Für detailliertere Informationen wird auf [Thom02] oder

http://ddi.cs.uni-potsdam.de/Personen/marco/vorl_ddi2_02/folien/DDI_Folien2.pdf verwiesen.

- Technische Modelle:

Hierzu zählen z.B. elektronische Modelle, Schaltkreise von Computern.

- Semantische Modelle:

Z.B. Kommunikationsmodelle: einerseits zwischen zwei Menschen untereinander und andererseits zwischen Menschen mit Computern.

- Graphische Modelle:

Traditionelle graphische Darstellungen sind z.B. Graphen, Bäume, Turingmaschinen usw.

Im Bereich der Softwareentwicklung sind graphische Modelle fester Bestandteil bei der Analyse, Entwurf und Implementierung von Software.

Es gibt eine Reihe von graphischen Modellen, die in der Entwicklung von Software eingesetzt wurden resp. immer noch werden. Zu denen zählen:

1. Entity Relationship Modell (ER – Modell)

2. Petri Netze

3. Relationsmodelle

4. Binäre Beziehungsmodelle

5. Einheitenzyklusdiagramm

6. UML (=Unified Modelling Language) (siehe Kapitel 3)

Ist die wohl bekannteste und am weitesten verbreitete Modellierungssprache in der Softwareentwicklung. Der Grund für die hohe Akzeptanz liegt sicherlich darin, dass sie zum anerkannten Industriestandard erhoben wurde. Gleichzeitig versucht man mit der UML alle anderen Modellarten zu vereinheitlichen und unter „einen Hut zu bringen“. Für eine Beschreibung aller Diagrammarten siehe Kapitel 3.

2.5 Zusammenfassung

Software – Engineering ist eine junge Ingenieurstätigkeit. Obwohl der Softwaremarkt zu den größten weltwirtschaftlichen Märkten gehört, wird er teilweise unterschätzt. Zahlreiche Softwarekatastrophen, die aufgrund ungenügender planmäßiger Vorgangsweise bei der Softwareentwicklung entstanden sind, verdeutlichen die Wichtigkeit einer konzeptionellen Entwicklung von Software. Dabei kommt den Softwareentwicklungsphasen Analyse und Entwurf eine bedeutende Rolle zu. In diesen Phasen entscheidet sich, ob ein Softwareprojekt in einem angemessenen Zeitrahmen erfolgreich beendet werden kann, oder ob Schwierigkeiten bereits in der Implementierungsphase auftreten. Außerdem bietet in diesen Phasen die UML eine perfekte Möglichkeit, Software zu planen resp. konzeptionell zu entwickeln

Neben dem technischen Endprodukt fallen im Laufe einer Softwareentwicklung zahlreiche zusätzliche Produkte an. Diese Produkte resp. Dokumente werden dafür verwendet, um einerseits die Qualität der Software sicher zu stellen und andererseits eine Kontrolle über den Projektfortgang zu haben.

Die Auswahl von geeignetem Personal für ein Softwareprojekt ist für einen positiven Fort – und Ausgang eines Projektes wichtig. Dabei wurde auch darauf hingewiesen, dass in größeren interdisziplinären Projekten oft externe Berater herangezogen werden müssen.

Modelle und Modelbildungen sind essentiell für die Informatik. Es wird anhand von Modellen versucht, die komplexe Umwelt mit Hilfe von Abstraktion und Strukturierung zu beschreiben. Erst diese Modelle ermöglichen uns, Lösungen für komplexe Zusammenhänge zu generieren. Bei der Modellierung wird bewusst Ungenauigkeit resp. „Nicht – Vollständigkeit“ in Kauf genommen. .

3 UML (Unified Modelling Language)

3.1 Einleitung

Wie bereits erwähnt, ist Unified Modelling Language (kurz: UML) eine objektorientierte Modellierungssprache, die versucht, ein Softwaresystem zu spezifizieren, zu modellieren resp. zu dokumentieren. Die „Idee“ und das „Ziel“ der UML ist einerseits die technische Komplexität (steigende Anforderungen an eine Software, ständige Wartung der Software etc.) und andererseits die soziale Kompetenz (Zusammenarbeit unterschiedlichster Menschen mit unterschiedlichen Zielsetzungen, große Anzahl an zusammenarbeitenden Personen mit unterschiedlichen natürlichen Sprachen usw.) eines Softwareentwicklungsprozesses zu „erleichtern“. Mit der UML versucht man, komplexe Softwarearchitekturen zu abstrahieren, dass sowohl der Programmierer als auch der Endanwender schon sehr früh in der Softwareentwicklungsphase in der Lage sind, die Architektur zu „verstehen“, die „Arbeitsweise“ der Software zu „begreifen“ und Zusammenhänge zu erkennen. Die Schwierigkeit dieser Modellierung liegt darin, den richtigen bzw. geeignetsten Abstrahierungsgrad zu wählen. Aus diesem Grund sind in der UML verschiedene Darstellungsarten in den einzelnen Softwareentwicklungsphasen vorgesehen. Diese Diagramme mit ihren UML – spezifischen Notationen werden in diesem Kapitel vorgestellt.

3.2 Historie der UML

Die ersten objektorientierte Konzepte in der Softwareentwicklung resp. objektorientierte Programmiersprachen (OOP) kamen vor ca. 30 Jahren auf. Die ersten OOP sind SIMULA und Ada9. Während SIMULA für die Entwicklung von Simulationssoftware eingesetzt wurde, unterstützte Ada9 bereits Packages und Tasks. Aus diesen Programmiersprachen entwickelten sich auch die heute bekannten wie Smaltalk-76 (1975) C++ (1985), Object Pascal (1985) u.a.

In den 90er Jahren kam dann erstmals die Idee für eine objektorientierte Modellierungssprache auf, wobei die Bücher von Booch, Coad und Yourdan, Rumbaugh, Jacobson, Shaler und Mellor, Martin und Odell u.a., zu den

Pionierwerken zählen. 1996 war das Ziel der OMG (Object Management Group), eine Vereinheitlichung der von den oben erwähnten Herrn beschriebenen Methoden. Die OMG erteilte Grady Booch, James Rumbaugh und Ivar Jacobson die Aufgabe, die UML zu standardisieren. Heute gelten Rumbaugh, Booch und Jacobson als die „Erfinder“ der UML. Schon ein Jahr später gab es schon die Version 1.0. Natürlich erkannten auch andere die Tragweiter der neuen Modellierungssprache und arbeiteten bei einer Verbesserung der 1.0 Version mit, sodass schon bald die 1.1, 1.2, 1.3 und die bei der Erstellung dieser vorliegenden Arbeit gültige Version 1.4 entstanden.

Seit 2002 ist die Version 2.0 geplant [vgl. Bezi01]. Die OMG hat nun die Einreichungen aller Einzelteile (Infrastruktur, Superstruktur etc.) angenommen. Als nächstes kommt die „Finalisierung“, d.h. Überarbeitung und Anpassung, damit die Einzelteile zusammenpassen. Eine offizielle Verabschiedung und Veröffentlichung ist nicht vor Anfang 2004 zu erwarten. Wie UML 2.0 jedoch aussehen wird, ist mit der Annahme jetzt jedoch weitgehend klar [vgl. auch Oest03].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 Geschichte UML, in Anlehnung an [Oest02]

3.3 Diagrammarten in der UML

3.3.1 Anwendungsfalldiagramm

Anwendungsfalldiagramme (engl. Use Case Diagramm) erlauben im frühen Stadium der Softwareentwicklung die Beschreibung der Funktionalität des zukünftigen Systems. Sie werden in der Analysephase modelliert und ermöglichen dem Kunden (späteren Benutzer) einen frühen Einblick in die zu erwartende Software.

Anwendungsfalldiagramme beschreiben die externe Sicht ins Systems: WAS soll das System können, das WIE bleibt vorerst unbeschrieben.

Ein Anwendungsfalldiagramm besteht aus einem Akteur, mehreren Anwendungsfällen und Beziehungen. Beziehungen können einerseits zwischen Akteur und Anwendungsfällen, und/oder andererseits zwischen Anwendungsfällen untereinander bestehen.

[...]

• Hochschule: Technische Universität Wien (rise Insitut Wien)
• Note: GUT +
• Autor: Mustafa Toktas, DI. (Autor:in)
• Erscheinungsjahr: 2003
• Seiten: 155
• Katalognummer: V42837
• ISBN (eBook): 9783638407748
• Sprache: Deutsch
• Schlagworte: Analyse, Werkzeuges, Modellierung, Software, Systemen