Softwareengineering - Informatik an der TU Clausthalreuter/ausarbeitung/Sebastian_Spautz... · Beschreibung der Module, die beim Entwurf entstehen mit deren Abhängigkeiten, Schnittstellen

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


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


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


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


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


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


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


Ä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


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


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


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


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

...

...


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


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


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


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


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


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


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


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



vom 16. Mai 2000

Subjekt Oriented Programming

Rico Basekow



vom 13. Juni 2000

Seite 20 von 21


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

Documents

Softwareengineering - Informatik an der TU Clausthalreuter/ausarbeitung/Sebastian_Spautz... · Beschreibung der Module, die beim Entwurf entstehen mit deren Abhängigkeiten, Schnittstellen