Page 1
Proseminar: Softwareengineering Sebastian Spautz
Softwareengineering
Eine Ausarbeitung des Proseminarvortrages aus
der Reihe Roboterfußball
Gehalten an der Technischen Universität Clausthal
im WS 2001/02
vorgetragen von
Sebastian Herbert Spautz
Leibnizstraße. 20/137
38678 Clausthal-Zellerfeld.E-Mail: [email protected]
Seite 1 von 21
Page 2
Proseminar: Softwareengineering Sebastian Spautz
Inhaltsverzeichnis:
1. Was versteht man unter Softwareengineering ...................................................... 3
2. Methoden des Softwareengineering
2.1 Das Phasenmodell ............................................................................... 4
2.2 Partizipative Systementwicklung ......................................................... 7
2.3 Qualitätssicherung ............................................................................... 7
2.4 Prototyping/ Rapid-Prototyping .......................................................... 8
2.5 Hierarchische Modularisierung ........................................................... 9
2.6 Strukturierte Programmierung ........................................................... 10
2.7 Objektorientierte Programmierung .................................................... 10
2.8 Subjektorientierte Programmierung ................................................... 11
2.9 Aspektorientierte Programmierung ................................................... 11
3. Hilfsmittel in der Softwareentwicklung
3.1 Flussdiagramme ............................................................................... 12
3.2 Struktogramme ................................................................................ 12
3.3 Datenflussdiagramme ...................................................................... 13
3.4 SADT-Methode .............................................................................. 13
3.5 HIPO-Methode ............................................................................... 15
3.6 Entity-Relationship-Modell .............................................................. 16
3.7 UML .............................................................................................. 16
3.8 Petrinetze ....................................................................................... 17
3.9 CASE-Tools ................................................................................... 19
4. Anhänge
4.1 Literaturangaben ............................................................................. 20
4.2 Handout zum Vortrag ..................................................................... 21
Seite 2 von 21
Page 3
Proseminar: Softwareengineering Sebastian Spautz
1. Was versteht man unter Softwareengineering?
Der Begriff Softwareengineering bedeutet im deutschen etwa Softwaretechnik oder
Programmiertechnik und ist im Informatik Duden wie folgt definiert:
„Softwareengineering ist die Anwendung von Prinzipien, Methoden und
Techniken auf den Entwurf und die Implementierung von großen
Softwaresystemen.“
Dieses, in obiger Definition dargestellte, ingenieurmäßige Vorgehen zeichnet das
Softwareengineering aus. In der sogenannten Softwarekrise um 1960 begann man Software
auf diese Weise zu 'produzieren'. Die Softwarekrise entwickelte sich aus dem künstlerischen
Ansatz zum Erstellen von Programmen und der wachsenden Komplexität der Systeme. Diese
kreative und künstlerische Ansicht der Programmierung ist nicht geeignet für größere
Softwareprojekte. Etwa 1960 kam es zu einem Punkt, in dem neue Vorgehensweisen nötig
wurden, um umfangreiche Software erstellen zu können. Es entwickelten sich unter diesen
Umständen verschiedene Methoden, Techniken und Prinzipien, die man heute unter dem
Begriff Softwareengineering zusammenfasst. Eine Auswahl dieser Komponenten des
Software-engineering werden in den Kapiteln zwei und drei dargestellt.
Die Ziele des Softwareengineering sind somit das Erreichen einer möglichst hohen Qualität
und die effiziente Entwicklung von Softwaresystemen.
Seite 3 von 21
Page 4
Proseminar: Softwareengineering Sebastian Spautz
2. Methoden des Softwareengineerin
2.1 Das PhasenmodelDas Phasenmodell, auch als „Software Life
Cycle“ bezeichnet, ist ein Modell der einzelnen
Zustände in denen sich eine Software befinden
kann. Rechts ist eine Wasserfalldarstellung
dieses Modells. Es heißt deshalb
Wasserfalldarstellung, weil idealerweise die
Phasen in linearer aufeinander folgen und nicht
mehr von einer späteren Phase erreicht werden
können. Allerdings werden in der Praxis öfter
Rück-schritte gemacht um das Ergebnis der
vorherigen Phasen zu verbessern.
Im folgenden werden die einzelnen Phasen im
Detail erläutert:
2.1.1 Die Problemanalyse-Phase dient dem
Erfassen des Ausgangsproblems und aller
wichtigen Umgebungsbedingungen. Desweiteren
wird die Durchführbarkeit geprüft. Innerhalb der
Problemanalyse wird eine Ist-Analyse durch-
geführt die ermittelt, welche vorhandenen
Systeme durch den Einsatz von Rechenanlagen
beeinflusst werden und welche Funktionen diese
ausführen und wie sie miteinander
kommunizieren. Allgemein werden die
Komponenten des Systems für das eine Software
entwickelt wird auf ihre bisherige Funktionalität
untersucht, um diese nachbilden zu können. Auf die Ist-Analyse folgt das Sollkonzept, welches die wesentlichen Systemziele, das
Benutzermodell, die Basismaschine, die Benutzermaschine und die
Seite 4 von 21
Abbildung 1 Das Phasenmodell als Wasserfalldiagramm
Problem
Anforderungsdefinition
Spezifikation
Problemanalyse
Entwurf
Implementierung
dokumentiertes Programm
Funktions-, Leistungs-überprüfung
Modifiziertes Programm
Installation, Abnahme
Anforderungsgerechtes Produkt
Wartung
Verschrottung, Wiederverwendung
Page 5
Proseminar: Softwareengineering Sebastian Spautz
Erweiterungsmöglichkeiten des zukünftigen Systems festlegt. Unter dem Benutzermodell
versteht man die Festlegung der beim Nutzer zu erwartenden und vorauszusetzenden
Kentnisse sowie die Nutzungshäufigkeit des Systems. Die Basismaschine meint die
grundlegenden und minimalen Eigenschaften, der Plattform, auf die die Software später
aufsetzt. Darunter fallen das Betriebssystem und die Betriebsmittel wie Ein- und
Ausgabegeräte. Im Gegensatz zur Basismaschine befasst sich die Benutzermaschine nicht mit
den technischen Grundlagen, sonder mit der Benutzerschnittstelle. Es werden bestimmt,
welches Fehlerverhalten, welches Format für Ein- und Ausgaben und welche Art der
Darstellung Verwendung finden. Dabei ist natürlich das Benutzermodell mit einzubeziehen,
da es den Benutzer beschreibt, der am System arbeitet.
Sobald das Problem erfasst wurde, sollte die Durchführbarkeitsstudie durchgeführt werden. In
ihrem Verlauf wird geprüft, ob eine Lösung für das Problem mit vertretbarem, zeitlichem und
materiellem Aufwand gefunden werden kann und natürlich auch ob es technisch überhaupt
realisierbar ist.
Zum Abschluss der Problemanalyse werden Arbeiten des Projektmanagement ausgeführt. Es
wird das Entwicklungsteam zusammengestellt, Strukturen und Hierarchien werden festgelegt.
Außerdem werden zeitliche und finanzielle Rahmenbedingungen geklärt.
Das Ergebnis der Problemanalyse ist eine Anforderungsdefinition. Dieses Dokument, auch
Pflichtenheft genannt, ist eine wichtige Grundlage für den Vertrag zwischen Auftraggeber und
Entwickler und muss daher präzise und verständlich formuliert sein.
2.1.2 Die Entwurf-Phase beinhaltet die Modellierung des gewünschten Systems. Dies sollte
ohne die Festlegung auf eine konkrete Programmiersprache erfolgen, um die Portabilität zu
gewährleisten. Die Modellierung erfolgt durch Zerlegung des Gesamtproblem in kleine
Einzelteile, die möglichst unabhängig voneinander sind. Dabei sollte ein transparentes und
nachvollziehbares Modell entstehen, dessen Zerlegungsstruktur die innere Struktur des
Ursprungproblems wiederspiegelt. Durch die Modularisierung entstehen mehrere Vorteile,
wie die Möglichkeit der Wiederverwendung bereits vorhandener Module oder die
Austauschbarkeit der Einzelteile. Aus der geforderten Unabhängigkeit ergibt sich die
Möglichkeit die Module getrennte zu testen.
Aus dieser fortschreitenden Zerlegung resultiert eine Spezifikation. Diese enthält eine
Beschreibung der Module, die beim Entwurf entstehen mit deren Abhängigkeiten,
Schnittstellen und Anwendungsmöglichkeiten.2.1.3 Die Implementierung wandelt die in der Entwurfs-Phase entstandenen Module und die
Seite 5 von 21
Page 6
Proseminar: Softwareengineering Sebastian Spautz
verbindende Struktur in ausführbaren Programmcode um. Wenn die einzelnen Bestandteile
existieren, werden sie zu einem lauffähigem Programm integriert, das der Anforderungs-
definition entspricht. Bei der Programmierung sind einige Grundsätzlichkeiten zu beachten,
die die Funktionsprüfung und die Qualitätsicherung unterstützen. Einige dieser Grundsätze
sind die Verwendung von verbreiteten Elementen, aussagekräftigen Bezeichnern und
vorgefertigten Programmteilen. Wenn man in einer problemorientierten Sprache (z.B. C, C++,
Java) implementiert, wird aus Effizienzgründen meist eine Optimierung auf Assemblerebene
durchgeführt.
Am Ende des Implementierens steht ein lauffähiges Programm mit der zugehörigen
Dokumentation. Diese enthält die Zusammenhänge zwischen der Spezifikation und der
Implementierung sowie eine Übersicht über den Programmaufbau und die verwendeten
Bezeichner. Auch die einzelnen Einheiten werden in der Dokumentation erläutert.
2.1.4 Funktions- und Leistungsüberprüfung: Wenn die Implementierung abgeschlossen ist,
werden umfassende Prüfungen vorgenommen, um die Korrektheit und Leistungsfähigkeit zu
bestimmen. Ob die, während der Problemanalyse spezifizierte Funktionalität erreicht wurde,
wird in vier Bereichen getestet.
Zuerst wird der Modultest ausgeführt. Dabei werden die einzelnen Einheiten auf ihre gemäß
der Spezifikation festgelegten Funktionen geprüft. Ein Großteil der Arbeit hierbei entsteht
durch das Entwerfen passender Testumgebung.
Nachdem die Einheiten als korrekt erkannt wurden werden sie in fortschreitendem Maße
integriert und das gemeinsame Verhalten im Integrationstest geprüft. Speziell steht dabei die
Kommunikation der Module im Mittelpunkt des Interesses.
Sobald das Softwaresystem richtig arbeitet, wird ein Installationstest durchgeführt, sofern es
nicht auf der Zielplattform entwickelt wurde. Hierbei wird darauf geachtet, dass die Software
mit den speziellen Eigenschaften der Zielplattform umgehen kann, damit keine Fehler durch
fehlerhafte Steuerung der Basismaschine entstehen können.
Abschließend wird im Abnahmetest eine Prüfung durch den Auftraggeber durchgeführt. Dies
stellt sicher, dass das Programm die Zielsetzung des Kunden auch erfüllt.
Die Leistungsüberprüfung ermittelt, ob das System auch Effizient genug ist, um die
anfallenden Arbeiten ausreichend schnell zu bewältigen. Hierzu wird unter anderem das
Laufzeitverhalten mittels umfangreicher Testdaten betrachtet.
Gegebenenfalls muss das System korrigiert und verbessert werden, so dass am Ende dieser
Phase eine korrigierte Fassung der Software steht.
Seite 6 von 21
Page 7
Proseminar: Softwareengineering Sebastian Spautz
2.1.5 Installation & Abnahme umfasst die Einführung des Softwaresystems beim Kunden.
Hierzu zählen die Installation der Basismaschine, die Schulung der Benutzer und das
Einrichten und Konfigurieren des Systems. Abschließend wird das Ergebnis vom Auftaggeber
begutachtet und bei dessen Zufriedenheit die Entwicklungsarbeit abgeschlossen. Zum
Auslieferungszustand gehört auch eine umfassende Dokumentation. Diese umfasst, im
Gegensatz zur Dokumentation, die aus der Implementierung hervorgeht, alle Dokumente, die
während der Entwichlungsarbeit entstanden sind. Die enthaltenden Informationen bereitet
man für verschiedenen Lesergruppen auf. Das Benutzerhandbuch umfasst verständlich
beschrieben den Gebrauch der Software und die Reaktionsmöglichkeiten auf
Fehlermeldungen. Die Entwicklerdokumentation enthält sowohl die Absprachen und Verträge
zwischen Auftraggeber und Entwickler als auch alle verwaltungstechnischen Dokumente wie
Aufgabenverteilung und Richtlinien des Teams sowie eine Systementwicklungsbeschreibung,
die alle Dokumente enthält, die zur Entwicklungszeit anfallen.
2.1.6 Wartung: Die meiste Software wird während ihrem Gebrauch mehrmals erweitert,
angepasst und nötigenfalls korrigiert, bis sie schließlich abgeschafft wird.
2.1.7 Aufwand beim Softwareengineering: Je nach Größe des Ausgangsproblems nimmt ein
Projekt unterschiedlich viel Zeit in Anspruch. Dabei entfallen auf den Entwurf und die
Prüfung je etwa 40% und die Implementierung 20%.
2.2 Partizipative SystementwicklungUnter 'Partizipativer Systementwicklung' versteht man die Einbeziehung des Auftaggebers und
dem zukünftigen Benutzer, der Software über die komplette Zeit der Systementwicklung. Die
Teilnahme des Auftraggebers sichert, dass das Auftragsziel erreicht wird. Die Benutzer-
freundlichkeit hingegen wird erhöht durch die Beteiligung des zukünftigen Nutzers.
2.3 QualitätsicherungQualität ist eine der wesentlichen Ziele, des Softwareengineerings. Die Qualität von Software
wird dabei in mehreren Bereichen betrachtet. Die Benutzerfreundlichkeit ist gut, wenn das
Programm eine leichte und intuitive Handhabung ermöglicht. Robust ist eine Software, die
auch bei fehlerhafter Bedienung weiter arbeitet und bei defekten einen sicheren Abschluss der
begonnenen Arbeitet ermöglicht und nicht abstürzt. Von Wartbarkeit spricht man, wenn die
Quellcodes verständlich, dokumentiert und kommentiert sind, so dass schnell und einfach
Seite 7 von 21
Page 8
Proseminar: Softwareengineering Sebastian Spautz
Änderungen vorgenommen werden können. Software, die durch klare Schnittstellen und eine
hohe Verständlichkeit leicht erweitert und angepasst werden können, nennt man dann
anpassbar. Weitere Qualitätskriterien sind die Portabilität auf verschiedene Plattformen, die
Effizienz der Software, die Genauigkeit der Lösung und die Ergonomie, die sich mit der
Anpassung der Software an menschliche Physiologie und Psychologie beschäftigt.
Diese Kriterien von Software werden durch verschiedene Verfahren sichergestellt. Dabei ist
zu beachten, dass nicht nur das Produkt, also die Software von diesen Maßnahmen betroffen
sind, sondern auch der Entwicklungsprozess. Dies ist wichtig, da eine hochwertige Software-
entwicklung Fehler verhindert, die später zu finden und zu korrigieren sehr aufwändig wäre.
Eine einfache Maßnahme sind Inspektionen. In ihrem Verlauf prüfen einzelne Personen
Softwarekomponenten auf Klarheit und Korrektheit. Meist geschieht dies durch
Nachvollziehen der Komponente und ihrer Dokumentation am Schreibtisch. Darüber hinaus
gehen Reviews. Hierbei prüft eine Gruppe von Gutachtern oder Kunden die Ergebnisse einer
Arbeit. Hierbei werden formelle Beweisverfahren zur Verifikation angewandt. Ein weiteres
Mittel, um Qualität sicherzustellen, sind regelmäßige und umfangreiche Tests. Es kann, vor
allem bei größeren Projekten, sinnvoll sein diese Arbeiten von unabhängigen Teams
durchführen zu lassen. Beim Testen ist zwischen Testläufen mit zufälligen Testdaten und
solchen, deren Daten gezielt konstruiert wurden, zu unterscheiden. Auch das Messen von
Größen, wie der Anzahl, der Programmzeilen und Modulen, der Laufzeit, dem benötigtem
Speicherplatz und der Menge, der gefundenen Fehler lässt sich zur Qualitätsbestimmung
heranziehen. Desweiteren hat es entscheidende Vorteile, einen Projektleiter mit der
Überwachung, der Entwicklung zu betrauen oder eine hierarchische Personalstruktur zu
etablieren, die diese Aufgabe übernimmt. Auch zum Qualitätsmanagement gehört es, sich
frühzeitig darauf zu einigen, welche Normen und übergeordneten Kriterien man einhält und
berücksichtigt.
Diese und weitere Maßnahmen zur Qualitätssicherung sind in den ISO Normen 9000 bis 9004
festgehalten. In Deutschland gibt es die DIN 9000 - DIN 9004 Normen, die aber auf den ISO
Normen beruhen.
2.4 Prototyping / Rapid-PrototypingDas Erstellen von Prototypen gehört zu den wichtigen Aufgaben beim Softwareengineering.
Ein Prototyp ist ein lauffähiges, aber teilweise stark eingeschränktes Modell des zukünftigen
Seite 8 von 21
Page 9
Proseminar: Softwareengineering Sebastian Spautz
Systems, an dem man bestimmte Aspekte oder Funktionen schon vor oder während der
Verwirklichung der Software untersuchen kann. Damit erlauben Prototypen ein frühzeitiges
Studieren der Eigenschaften und Fähigkeiten des Anwendungssystems. Je nachdem, wie nahe
der Prototyp den Projektzielen kommt, spricht man von einem Labormuster, von einem
Demonstrationsmodell oder einem Pilotsystem. Beim Labormuster handelt es sich um ein
Anschauungsobjekt für die Entwickler und das Demonstrationsmodell dient der Vorführung
beim Kunden. Mit dem Pilotsystem lassen sich erste Fallstudien in einer realistischen
Umgebung machen, da es schon fast dem entgültigen System entspricht und zum Beispiel
beim Kunden installiert werden kann.
Das Rapid-Prototyping ist eine spezielle Art des Prototyping. Dieser besondere Prototyp wird
in der Problemanalysephase erstellt, um die Anwendungsdefinition zu präzisieren. Dabei ist
zu bedenken, dass es sich hierbei um ein 'Wegwerfmodell' handelt, das sich in keiner Weise
auf den Entwurf und die Implementierung auswirken sollte, da er nur zur Veranschaulichung
der Ausgangssituation entwickelt wird.
2.5 Hierarchische ModularisierungUnter Hierarchischen Modularisierung versteht man das Aufteilen des Gesamtproblems in
Einzelbausteine. Dazu wird eine fortschreitende Verfeinerung der Module verwendet. Damit
ist die Hierarchische Modularisierung eine Technik, die vor allem im Entwurf Verwendung
findet. Durch die Modularisierung werden mehrere Vorteile erreicht, die die
Softwareentwicklung erleichtern.
Wenn einzelne Module sehr allgemeine Aufgaben ausführen sollen, findet man für diese
wahrscheinlich bereits vorhandene Lösungen. Die Module, die neu geschrieben werden
müssen, können auf einzelne Entwickler verteilt werden. Dabei entsteht ein weiterer Vorteil.
Nicht jedes Teammitglied muss sich das komplette Fachwissen, das zum Verständnis der
Problemstellung nötig währe, aneignen, sondern nur soviel, dass er die ihm zugeteilten
Module verwirklichen kann. Eine wichtige Eigenschaft der Modularisierung im Hinblick auf
die Wartung und Fehlerbeseitigung ist die Austauschbarkeit eines Modules, durch eines mit
gleicher Funktionalität.
Bei der Hierarchischen Modularisierung unterscheidet man zwei grundlegende Strategien. Die
Top-Down Methode zerlegt ein komplexes Gesamtproblem in immer stärkerem Maße in
einfachere Teile. Bei der Bottem-Up Methode erhält man hingegen aus mehreren vorhandenen
Seite 9 von 21
Page 10
Proseminar: Softwareengineering Sebastian Spautz
Systemen, durch Zusammenfügen ein komfortableres Gesamtprogramm. Grundsätzlich ist die
Top-Down Methode der Bottem-Up Methode vorzuziehen, aber in der Praxis werden oft
gemischte Strategien verwendet. Diese nennt man Jo-Jo-Methode.
2.6 Strukturierte ProgrammierungDiese spezielle Form der Hierarchischen Modularisierung im Top-Down Verfahren folgt
einem problemorientierten Ansatz. Das bedeutet, die durch die Modularisierung gegebene
Zerlegung erfolgt, indem die innere Struktur des Ausgangsproblems ausgenutzt wird, um
daraus viele einzelne Problemstellungen zu isolieren, die zusammen wieder dem
Hauptproblem entsprechen. Diese Teilprobleme müssen unabhängig implementierbar sein,
um die Vorteile der Hierarchischen Modularisierung zu erreichen. Beim Entwurf eines
Systems mit dieser Methode ist darauf zu achten, dass man sich nicht von der Struktur einer
möglichen späteren Programmiersprache oder Plattform in der Zerlegung beeinflussen lässt.
Dies gewährleistet eine leichte Portabilität.
2.7 Objektorientierte ProgrammierungBeim Objektorientierten Entwurf steht nicht das Problem im Vordergrund, sondern die
Objekte, die zur Lösung der Situation herangezogen werden. Die Ausgangssituation wird in
Objekte zerlegt. Bei diesen werden die Kommunikation, der Datenaustausch sowie
Zustandsänderungen betrachtet. Objekte mit gleichen inneren Strukturen und Methoden
werden zu Klassen zusammengefasst. Dabei kann ein Objekt, das eine spezielle Ausprägung
einer Klasse darstellt, die gemeinsamen Eigenschaften von dieser Klasse übernehmen und um
ihre erweiterten Charakteristika ergänzen. Diesen Vorgang nennt man Vererbung. Die
vererbende Klasse heißt Superklasse und die erbenden Objekte gehören zu einer Subklasse,
die selbst wieder zur Superklasse werden kann. Weitere Eigenschaften des Objektorientierten
Paradigmas ist die Kapselung. Damit ist gemeint, dass eine Klasse und somit die ihr
angehörenden Objekte ihre innere Struktur nach außen nicht sichtbar machen. Für die
Integration der Objekte zu einem Gesamtsystem ist dies vorteilhaft, da man sich nur noch mit
den Schnittstellen der Objekte befassen muss und nicht mit ihrem Aufbau. Einem
objektorientierten Entwurf muss auch eine Implementierung in einer objektorientierten
Sprache wie Java oder C++ erfolgen.
Seite 10 von 21
Page 11
Proseminar: Softwareengineering Sebastian Spautz
2.8 Subjekt Orientierte Programmierung (SOP)SOP erweitert das objektorientiert Konzept um Subjekte. Bei diesen Subjekten handelt es sich
um Container für Klassen und andere Subjekte. Dieses weitere Strukturelement verbessert die
Entwicklung von großen Softweresystemen, da diese in mehrere unabhängige Subjekte
getrennt, von mehreren Entwicklungsgruppen, erstellt werden können. Eine flexible
Kombination von Subjekten wird ermöglicht durch frei definierbare Kompositionsregeln.
Diese erlauben es auch umfangreiche Änderungen oder Erweiterungen einfach in ein auf SOP
basierendem System zu integrieren. Subjekte sind ähnlich den Klassen, der reinen
Objektorientierten Programmierung, gekapselte Einheiten, die sich nach außen mit ihren
Schnittstellen und Funktionsaufrufen präsentieren.
2.9 Aspekt Orientierte Programmierung (AOP)Das AOP-Konzept ist eine weitere Entwurfstechnik. Hierbei wird das Ausgangsproblem in
sogenannte Komponenten und Aspekte zerlegt. Komponenten stellen die Grund-
funktionalitäten dar und Aspekte sind übergreifende und spezielle Funktionen. Der
wesentliche Vorteil des AOP ist, dass die Komponenten und Aspekte getrennt und
nötigenfalls in verschiedenen Sprachen implementiert werden können. Die Bestandteile
werden dann zur Laufzeit von einem Aspect Weaver zusammengefügt. Dieses Verfahren soll
den Code, durch die Trennung leichter verständlich machen und die Wartbarkeit erhöhen.
AOP ist vor allem für die Programmierung verteilter Systeme entwickelt worden.
Seite 11 von 21
Page 12
Proseminar: Softwareengineering Sebastian Spautz
3. Hilfsmittel in der Softwareentwicklung
3.1 FlussdiagrammeFlussdiagramme sind eine normierte Form der graphischen Darstellung von Programmen.
Flussdiagramme werden auch als Programmablaufplan, oder einfach Ablaufplan, bezeichnet.
Bei der Darstellung werden Symbole für Aktionen, Bedingungen, Unterprogrammaufrufe und
andere Aktionen innerhalb eines Programms mit Pfeilen verbunden. Hier einige Beispiele für
die verwendeten Symbole:
Durch die lineare Struktur der Flussdiagramme lassen sich keine Schleifen und Rekursionen
darstellen. Damit sind die Programmablaufpläne nur geeignet, um lineare Programmteile oder
kleine Programme darzustellen.
3.2 StruktogrammeStruktogramme, oder auch Nassi-Shneidman-
Diagramme, sind jünger als die oben besprochenen
Flussdiagramme und beseitigen einige deren Mängel.
So lassen sich in Struktogrammen Schleifen darstellen.
Die Darstellung erfolgt mittels Strukturblöcken. Das
sind Rechtecke in denen die Art der ausgeführten
Aktion eingetragen wird. Der Programmablauf wird
durch Aneinanderreihen der einzelnen Blöcke
verdeutlicht. Die beiden Abbildungen enthalten die
üblichen Elemente für eine Fallauswahl, eine bedingte
Seite 12 von 21
Abbildung 2 Symbole in Flussdiagrammen
A k tion
S ym bol fü r e in fa ch e A k tion en
B ed in g u n gN einJa
E in g a be
S ym bol fü r e in e V er z w eig u n g S ym bol fü r e in e E in g a be
Abbildung 3Elemente in Struktogrammen 1
A ktionFallauswah l
Fall 1 Fall 2 ...A ktion A ktion
wh ile
A ktion
...
...
Page 13
Proseminar: Softwareengineering Sebastian Spautz
Anweisung, eine while-Schleife und eine until-Schleife. Bei
Struktugrammen ist die Darstellung von Schleifen und
Fallunterscheidungen übersichtlich, aber trotzdem nimmt die
Komplexität bei großen oder sehr tief geschachtelten
Programmen schnell zu. Daraus folgt eine Verwendung von
Struktogrammen hauptsächlich für Programmteile.
3.3 DatenflusspläneEine, den Flussdiagrammen sehr ähnliche Art der Darstellung, verwenden die
Datenflusspläne. Dabei stellen sie aber nicht den Programmablauf da, sondern die
Veränderungen der Eingabedaten im Verlauf der Bearbeitung. Dazu stehen Symbole für
verschiedene Speichermedien, und manuelle Eingaben bereit. Es existiert ein normierter Satz
von Symbolen, um Datenflusspläne darzustellen. Die DIN Norm hierzu hat die Nummer
66001. In der Softwareentwicklung werden Datenflusspläne genutzt, um die Ist-Analyse
innerhalb der Problembetrachtung zu formalisieren. Ansonsten finden sie immer Verwendung,
wenn es wichtig ist, den Verlauf der Daten und nicht so sehr die Programmstruktur zu
betrachten. Bei den betrachteten Systemen muss es sich nicht unbedingt um Computersysteme
handeln. Es gibt zum Beispiel auch Symbole für Schriftstücke. Dies ist für die Ist-Analyse
auch notwendig um auch die bisherige Situation bei Erstanschaffung einer Rechenanlage zu
beschreiben.
Hier noch einige Beispiele für Sinnbilder, nach DIN 66001, die in Datenflussplänen
Verwendung finden:
Seite 13 von 21
Abbildung 5 Symbole in Datenflussplänen
Symbol fürallgemeineAktionen
Symbol fürmanuelle Eingabe
Symbol fürDaten aufMagnetband
Symbol fürDaten aufMagnetplatten-speicher
Symbol fürDaten aufSchriftstücken
Abbildung 4 Elemente inStruktogrammen 2
Aktion
until
Aktion
...
Bedingungja nein
Aktion Aktion
Page 14
Proseminar: Softwareengineering Sebastian Spautz
3.4 SADT-MethodeSADT ist eine Abkürzung für Strucured Analysis and Design Technique. Zu Deutsch bedeutet
dies Strukturierte Analyse und Entwurfstechnik. Wie aus dem Namen schon hervorgeht,
unterstützt die SADT-Methode die Problemanalyse-
Phase und den Entwurf. Bei Anwendung der SADT-
Methode werden Diagramme aus Kästen und Pfeilen
erstellt. Jedes zu betrachtende System wird dabei auf
zwei Weisen dargestellt, einmal unter einem
funktionalen Aspekt und ein zweites mal unter einem
objektbezogenen Aspekt. Die Kästen der Graphik
enthalten dabei im ersten Fall die Funktion und im
zweiten Fall das Objekt. Bei der funktionalen Ansicht symbolisieren die von Links
kommenden Pfeile die Eingaben, nach rechts gehen die Ausgaben, von oben kommen
Steuerdaten und unten sind Mechanismen zur Verarbeitung an die Pfeile angetragen. Die
Pfeile der objektbezogen Ansicht haben folgende Bedeutung: Von links kommen Funktionen
zum Erzeugen von Objekten, rechts verlassen einzelne Instanzen des Objekts dieses, oben
werden Steuerdaten eingetragen und von unten kommen Mechanismen wie Aufenthaltsorte
des Objektes. Hierzu ein kleines Beispiel: Hierbei handelt es sich um eine funktionale Ansicht
eines Verwaltungssystems für ein
Ersatzteillager. Teile werden
angeliefert und Bestellungen gehen
ein, das Personal arbeitet aufgrund der
Kostenvorgabe und der
Lagerbestandspolitik und Bestellungen
und Lieferungen gehen aus. SADT-
Modelle sind hierarchisch aufgebaut.
Das heißt, ein einzelnes Diagramm
kann durch eines mit mehreren
Funktionen oder Objekten ersetzt
werden. Dies ermöglicht, das System auf sehr unterschiedlichen Abstraktionsebenen
betrachten zu können. Dabei kann die fortschreitende Verfeinerung den Prozess der
hierarchischen Modularisierung simulieren.
Seite 14 von 21
Abbildung 6 SADT Grundelement
FunktionoderObjekt
Abbildung 7 Beispiel zur SADT-Methode
verwalte Ersatzteillager
Kostenvorgaben
Lager-bestandsPolitik
Teilelieferung
Bestellungenvon Kunden
Bestellungen anHersteller
Lieferung anKunden
Personal
Page 15
Proseminar: Softwareengineering Sebastian Spautz
3.5 HIPO-MethodeDie HIPO-Methode ist ein Verfahren zur Beschreibung des Eingabe-Ausgabe-Verhaltens von
Systemen. Hierzu verwendet man Abbildungen, die den Übergang der Eingabe in die Ausgabe
verdeutlichen. Dies spiegelt sich auch im Namen dieser Methode wieder: Hierarchy of Input-
Process-Output. Ebenfalls im Namen enthalten ist die hierarchische Struktur der Diagramme.
Ein HIPO Diagramm enthält eine Menge von Prozessen, von denen sich jede wieder als HIPO
Diagramm darstellen lässt. Diese hierarchischen Abhängigkeiten werden in einem Baum
festgehalten. Bei den Diagrammen handelt es sich um drei Felder, die in einem gemeinsamen
Rahmen eingebettet sind. Im linken Feld stehen die Eingaben, rechts folgt eine Liste von
Funktionen und ganz außen die dadurch bedingten Ausgaben. Diese Darstellungsform bedingt
einige Schwierigkeiten bei nichtlinearen Programmen, bei der Darstellung von Zwischendaten
und bei Modulen ohne Eingaben. Erstere sind nicht darstellbar, da keine Schleifen zur
Verfügung stehen. Bei den Zwischendaten muss man sich einigen, wo man sie einträgt, bei
den Eingaben oder bei den Ausgaben. Dadurch sind solche Situationen nicht eindeutig.
Module ohne Eingabe, wie Zugriffsfunktionen auf Datenstrukturen, enthalten keine über
Funktionen beschreibbare Form und sind somit ebenfalls nicht darstellbar.
Die HIPO-Methode findet beim Softwareengineering vorallem beim Entwurf Verwendung,
wo sie die Arbeitsgänge der Software veranschaulicht.
Seite 15 von 21
Abbildung 8 Beispiel zur HIPO-Methode
Hauptprozess
Eingabe Verarbeitung Ausgabe
Eingabe 1Eingabe 2Eingabe 3Eingabe 4
Prozess 1Prozess 2Prozess 3
Ausgabe 1Ausgabe 2
0
Prozess 1
Eingabe Verarbeitung Ausgabe
Eingabe 1Eingabe 2
Ausgabe 1Subprozess 1
ZwischendatenSubprozess 2
Page 16
Proseminar: Softwareengineering Sebastian Spautz
3.6 Entity-Relationsship-ModellDiese Form eines Datenmodells arbeitet auf Basis von Beziehungen zwischen Dingen, auf
Englisch entities. Dabei ist zu beachten, dass Entity-Relationsship-Modelle voraussetzen, dass
die in ihnen enthaltenden Entities eindeutig voneinander unterscheidbar sind. Diese Merkmale
eines Gegenstandes nennt man Attribute. Bei Attributen, die die Eindeutigkeit eines Entity
gewährleisten, spricht man von einem Schlüssel. Auch Beziehungen, sogenannte
Relationsships, können durch Attribute näher spezifiziert werden.
Die Darstellung erfolgt mittels dreier Symbole: Rechtecke für Entities, Karos für Beziehungen
und Ovale für Attribute. Das folgende Beispiel zeigt die Zusammenhänge zwischen
Programmierern, ihrem Entwicklungsteam und einem Projekt.
Die Entity-Relationsship-Modelle sind ein vielseitiges Werkzeug um Ausschnitte der reellen
Welt darzustellen. Beim Softwareengineering setzt man sie in der Entwurfs-Phase ein um die
Spezifikation zu verdeutlichen.
3.7 UMLDie Unified Modeling Language (dt. vereinheitlichte Modellierungssprache) dient dem
Verdeutlichen von Ideen, Modellen, Vorgehensweisen und Lösungen. Dabei werden
hauptsächlich Diagramme verwendet. Diese unterscheiden sich je nach dem, was dargestellt
werden soll. Einige wichtige Beispiele für Diagramme in UML sind Objektdiagramme,
Klassendiagramme, Kollaborationsdiagramme und Sequenzdiagramme. Wie die Namen der
Seite 16 von 21
Abbildung 9 Beispiel zu Entity-Relationsship-Modellen
Name Personal-Nr.
Spezialisierung
Programmierer
arbeitet in
Entwicklungsteam
Finanzrahmen
Teamleiter
entwickeltProjekt
ProjektTitel
Kunde
arbeitet an
Page 17
Proseminar: Softwareengineering Sebastian Spautz
ersten beiden Diagrammtypen vermuten lassen, unterstützt UML den objektorientierten
Entwurf und lässt sich daher leicht in Objektorientierte
Sprachen umsetzen. So kann man aus einem Entwurf in
UML schnell Prototypen erstellen. Die Objektdiagramme
stellen konkrete Objekte da. Im oberen Teil steht der Name
des Objektes und die Klasse, der das Objekt angehört. Im
unteren Teil stehen Informationen über das Objekt. Im
speziellen sind dies der Zustand, in dem sich das Objekt befindet, und die aktuell zulässigen
Methoden. Die Klassendiagramme sind den Objektdiagrammen sehr ähnlich. Oben ist die
Klasse, um die es sich handelt, eingetragen und darunter ihre
Datenstruktur, also die Attribute. Auch die Methoden, die
angewandt werden können, werden hier eingetragen. Die Objekt-
und Klassendiagramme können mit anderen ihrer Art verbunden
werden, um die Beziehungen, Abhängigkeiten und Kom-
munikationswege zu verdeutlichen. so entsteht ein Netz aus
Diagrammen, das das betrachtete System in seiner Gesamtheit
verdeutlicht. Bei dem Kollaborationsdiagramm werden Operationen und die an ihnen
beteiligten Objekte betrachtet. Dazu werden die Objekte miteinander verbunden und die
Beteiligung an der Operation an die Kanten geschrieben. Auch die zeitliche Abfolge kann
mittels Zahlen an den Kanten
verdeutlicht werden. Bei den
Sequenzdiagrammen wird das
Laufzeitverhalten betrachtet. Ebenfalls
gut zu sehen ist bei dieser Form die
Nebenläufigkeit des Systems.
Mit Hilfe der Modellierungsfähigkeiten
von UML lässt sich die Entwurfsphase
vereinfachen. UML hat sich seit 1997 in
der Praxis bewährt und wird intensiv
eingesetzt.
3.8 PetrinetzePetrinetze, benannt nach C. A. Petri, eignen sich zur Beschreibung von dynamischen
Seite 17 von 21
Abbildung 10 Objektdiagramm in UML
Objekt: Klasse
Zustand des Objekteszulässige Methoden
Abbildung 11 Klassendiagrammin UML
Klasse
AttributeMethoden
Abbildung 12 Sequenzdiagramm in UMLZeit
Objekt 1 Objekt 2 Objekt 3
Objekt 4
Objekt 5
Objekt 6Objekt
Page 18
Proseminar: Softwareengineering Sebastian Spautz
Systemen mit einer festen Grundstruktur. Diese Bedingungen erfüllen zum Beispiel auch
Rechenanlagen und Betriebssysteme. Speziell können mit Petrinetzen Nebenläufigkeit und
nicht-deterministische Systeme dargestellt werden. Petrinetze sind gerichtete Graphen mit
zwei Arten von Knoten: den Transitionen
und den Stellen. Die Transitionen, durch
Balken dargestellt, symbolisieren eine
Verarbeitung von Daten. Stellen sind
Zwischenspeicher und werden durch
Kreise dargestellt. Die Stellen können
gewichtet werten. Das bedeutet sie werden
mit Punkten versehen von denen jede ein
Objekt symbolisiert. Um das Verhalten eines Systems zu untersuchen, werden die
Transitionen 'geschaltet'. Wenn eine Transition geschaltet wird, wird von jeder eingehenden
Stelle ein Objekt entfernt und zu jeder ausgehenden Stelle ein Objekt hinzugefügt. Ein
Schaltvorgang kann nur durchgeführt werden, wenn alle eingehenden Stellen belegt sind. Dies
ist eine sehr einfache Form der Petrinetze. Man kann Petrinetze erweitern, um ihre
Darstellungsfähigkeiten zu erhöhen. Dazu legt man beispielsweise eine Kapazität der Stellen
fest, die die maximale Anzahl von Objekten
in dieser Stelle festlegt. Eine weitere
Möglichkeit, Petrinetze zu erweitern sind
Gewichtungen der Kanten. Diese
ermöglichen es, mehrere Objekte
gleichzeitig abzuziehen oder zufließen zu
lassen.
Man kann mit Petrinetzen prüfen, ob ein
System jemals stehen bleibt, da keine Transition mehr schalten kann oder man prüft auf
Erreichbarkeit. Dabei möchte man wissen, ob eine Situation in eine andere übergehen kann.
Diese zwei Anwendungen sind nur Beispiele. Es gibt noch wesentlich mehr
Verwendungszwecke.
Um die abstrakte Beschreibung leichter verständlich zu machen, hier ein kleines Beispiel:
Es gibt zwei Systeme, die auf den selben Drucker zugreifen wollen. In Abbildung 13 und 14
wird ein Petrinetz hierfür dargestellt. Die Transitionen t1 bzw. t2 belegen den Drucker und die
Transitionen t2 und t4 geben ihn wieder frei. In Abbildung 13 ist der Drucker frei, da die
Seite 18 von 21
Abbildung 13 Beispiel zu Petrinetzen 1
t1
t2
t3
t4
Abbildung 14 Beispiel zu Petrinetzen 2
t1
t2
t3
t4
Page 19
Proseminar: Softwareengineering Sebastian Spautz
auslaufenden Stellen von t1 und t2 leer sind. Beide Systeme können auf den Drucker
zugreifen, da die einlaufenden Stellen alle belegt sind. Dann wird t3 geschaltet und das
zugehörige System 2 belegt den Drucker. System 1 kann jetzt nicht auf den Drucker zugreifen,
da die mittlere Stelle des Petrinetzes nicht belegt ist (Abbildung 14).
3.9 CASE-ToolsCASE steht für computer aided software engineering, also Computer gestützte
Softwareentwicklung. Unter diesem Begriff fasst man alle Werkzeuge zusammen die bei der
Planung, dem Entwurf, der Entwicklung, der Implementierung, der Verwaltung, der
Dokumentation zum Einsatz kommen. Dazu zählen unter anderem Entwicklungsumgebungen,
Editoren für die in diesem Kapitel aufgeführten graphischen Hilfsmittel, automatische
Analysesverfahren und Programme zur Versionskontrolle.
Unter einer CASE-Umgebung versteht man dagegen eine Software, die in sich vereinigt, für
jede Phase des Softwareengineering mindestens ein Hilfsmittel bereithält.
Seite 19 von 21
Page 20
Proseminar: Softwareengineering Sebastian Spautz
4. Anhang
Anhang 4.1 LiteraturangabenDuden Informatik
Ein Fachlexikon für Studium und Praxis
Herausgeber: Meyers Lexikonredaktion
Dudenverlag
3. Auflage
Aspect Oriented Programming: D
Dennis Schroeder
Ausarbeitung zu einem Vortrag der Seminarreihe Softwaretechnik
der Technischen Universität Berlin
vom 9. Mai 2000
Aspect Oriented Programming: AspectJ
Ralf Ramrath
Ausarbeitung zu einem Vortrag der Seminarreihe Softwaretechnik
der Technischen Universität Berlin
vom 16. Mai 2000
Subjekt Oriented Programming
Rico Basekow
Ausarbeitung zu einem Vortrag der Seminarreihe Softwaretechnik
der Technischen Universität Berlin
vom 13. Juni 2000
Seite 20 von 21
Page 21
Proseminar: Softwareengineering Sebastian Spautz
Anhang 4.2 Handout zum Seminar
Proseminar an der Technischen Universität Clausthal
von Sebastian Spautzam 30.November 2001
Softwareengineering
INHALT
1. Was versteht man unterSoftwareengineering
2. Methoden desSoftwareengineering
a.)Das Phasenmodellb.)Partizipative Systementwicklungc.)Qualitätssicherungd.)Prototyping /Rapid-Prototypinge.)Hierarchische Modularisierungf.)Struckturierte Programmierungg.)Objektorientierte Programmierungh.)Weiter Methoden
3. Hilfsmittel in der Software- Entwicklung
a.)Flussdiagramme& Strucktogrammeb.)Datenflussplänec.)SADT - Methoded.)HIPO - Methodee.)Entity-Relationsship-Modellf.)UMLg.)Petrinetzeh.)CASE
Seite 21 von 21
Zeichnung 1Software Life Cycle
Problem
Anforderungsdefinition
Spezifikation
Problemanalyse
Entwurf
Implementierung
dokumentiertes Programm
Funktions-, Leistungs-überprüfung
Modifiziertes Programm
Installation, Abnahme
Anforderungsgerechtes Produkt
Wartung
Verschrottung, Wiederverwendung