Skip to main content
Disciplines
Automotive Business IT + Informatics Construction + Real Estate Electrical Engineering + Electronics Energy + Sustainability Insurance + Risk Finance + Banking Management + Leadership Marketing + Sales Mechanical Engineering + Materials
Events
DE
EN
Books
Journals
Topic Page
Marketing
Start single access now
Access for companies
EXTENDED SEARCH
Log in
Top

2018 | Book

Was ist Software-Engineering? Read chapter Read first chapter

Grundkurs Software-Engineering mit UML

Der pragmatische Weg zu erfolgreichen Softwareprojekten

Author: Prof. Dr. Stephan Kleuker

Publisher: Springer Fachmedien Wiesbaden

Part of: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Login to get access
insite
SEARCH

About this book

Mit der Entwicklung neuer Technologien werden auch die einzelnen Software-Projekte stetig komplexer. Zu analysieren, warum manche Projekte scheitern und andere erfolgreich sind, wird daher immer wichtiger. Dieses Buch ist ein praktischer Leitfaden für die Entwicklung neuer Software. Systematisch beschreibt der Autor die Chancen und Risiken, die einem bei der Entwicklung einer Software begegnen können. Vom gemeinsamen Kundengespräch, das Anforderungen und Ziele der Software festlegt, über die erste Modellierung bis hin zur systematischen Erfassung der Anforderungen zeigt er, wie die unterschiedlichen Prozesse mit Hilfe der UML (Unified Modeling Language) koordiniert werden können. Diese Modellierungssprache hilft, die Ideen des Entwicklers nachzuvollziehen und die Erfahrungen aus erfolgreichen Projekten auf andere Projekte zu übertragen.Neben Maßnahmen zur Qualitätssicherung beschreibt das Buch weitere Ansätze zur Projektplanung und Projektdurchführung und zeigt, wie die Softwareentwicklung in den Gesamtprozess eines Unternehmens eingebettet ist. Zum Verständnis des Buches werden Grundkenntnisse in einer objektorientierten Programmiersprache wie Java, C# oder C++ vorausgesetzt. Durch zahlreiche Wiederholungsfragen und Übungsaufgaben am Ende der Kapitel wird dieses Buch zum idealen Begleiter für Studenten der Informatik und verschiedener Ingenieurswissenschaften. Aber auch erfahrene Entwickler können von den vielen Kommentaren zur Verwendung in der Praxis zur kontinuierlichen Weiterentwicklung des Software-Engineerings profitieren. Die vorliegende vierte Auflage des bewährten Buches enthält erneut wichtige Erweiterungen und Ergänzungen.

Table of Contents

Frontmatter
1. Was ist Software-Engineering?
Zusammenfassung
Erinnern Sie sich an Ihre ersten Programmiererfahrungen? Bei mir dauerte es einige Zeit, bis ich die Grundkonstrukte verstanden hatte. Danach war ich der Meinung, dass mir die Welt aus der Sicht zu erstellender Programme zu Füßen liege, da immer größere Programme sich nach meinem Willen verhielten. Natürlich gab es in dieser Entwicklung Höhepunkte mit laufenden Programmen und viele Tiefpunkte mit scheinbar unlösbaren Problemen, bis zur vermeintlichen Sicherheit, dass der Fehler irgendwo im Computer selbst und nicht im gerade geschriebenen Programm liegen müsste. Ohne die Erfahrung anderer Personen, die halfen, Fehler zu entdecken und viele Tipps und Tricks kannten, größere Programme zum Laufen zu bringen, wäre ich auch nicht weitergekommen. Diese Form der Systematik mit der Einbeziehung der Erfahrungen Anderer, mit der immer wiederkehrende Probleme nicht immer erneut gelöst werden müssen, mit der die Kreativität des Programmierens auf neue Herausforderungen gerichtet wird, ist die Kernmotivation des Software-Engineerings, dessen Motivation und Definition in diesem Kapitel genauer betrachtet wird.
Stephan Kleuker
2. Prozessmodellierung
Zusammenfassung
In Software-Projekten arbeiten meist viele Personen aus unterschiedlichen Bereichen eines Unternehmens zusammen. Neben Informatikern, die überwiegend in der eigentlichen Entwicklung beschäftigt sind, sind dies Personen, die das Projekt, evtl. die Abteilung, in der das Projekt läuft, oder auch das gesamte Unternehmen managen. Für jede Entscheidung gibt es Personen, die die notwendigen Informationen als Entscheidungsgrundlage liefern und die mit der Aufbereitung dieser Informationen beschäftigt sind. Dies geht über Sekretariate, die Informationen über verbrauchte Stunden zusammenstellen, bis hin zum Controlling-Bereich, in dem die finanziellen Randbedingungen geprüft werden.
Mitarbeiter arbeiten in Software-Projekten in unterschiedlichen Rollen. In größeren Projekten gibt es Spezialisten, die die Anforderungen klären, die durch die Software zu erfüllen sind. Weiterhin gibt es Personen, die die Implementierung durchführen, und häufig andere, die prüfen, ob die entwickelte Software die Anforderungen erfüllt. Natürlich kann eine Person auch verschiedene Rollen in einem Projekt haben. Diese Abläufe gilt es zu erfassen und systematisch zu modellieren.
Stephan Kleuker
3. Vorgehensmodelle
Zusammenfassung
Im vorherigen Kapitel wurde gezeigt, dass es generell wichtig ist, die Vorgehensweisen zu beschreiben, damit die Zusammenarbeit in großen Unternehmen funktioniert. Daraus leitet sich für die Software-Entwicklung die Frage ab, wie hier die beste Vorgehensweise aussieht.
Diese Frage wurde und wird von Experten heftig diskutiert. Die daraus gewonnenen Erkenntnisse lassen sich wie folgt zusammenfassen und werden in diesem Kapitel konkretisiert:
  • Es gibt einzelne Teilprozesse, die typischerweise in jedem Software-Projekt vor-kommen, dies sind: Anforderungsanalyse, Design, Implementierung sowie Test und Integration. All diese Prozesse werden von Qualitätssicherungsmaßnahmen begleitet.
  • Die Bedeutung dieser Teilprozesse hängt von sehr vielen Faktoren ab, wichtige Beispiele sind: Größe des Projektes, Erfahrungen des Projektteams mit vergleich-baren Aufgaben und besondere Qualitätsanforderungen z. B. bei Software, die mit für Menschenleben verantwortlich ist.
  • Es gibt Prozesse, die für die Unterstützung der Software-Entwicklung wichtig sind, die sich z. B. mit der Bereitstellung der richtigen Entwicklungsumgebung beschäftigen.
  • Die Zusammenhänge zwischen den Teilprozessen und ihre individuellen Ausprägungen sind in den existierenden Prozessmodellen sehr unterschiedlich.
Stephan Kleuker
4. Anforderungsanalyse
Zusammenfassung
Da mit der Anforderungsanalyse der Einstieg in die systematische Software-Entwicklung stattfindet, hat diese Phase eine besondere Bedeutung für Software-Projekte. Hier gilt die einfache Aussage „Garbage in, garbage out“, da es in einem Projekt praktisch nicht möglich ist, mangelhafte Ergebnisse einer Anforderungsanalyse durch besondere Qualität in späteren Phasen wieder auszugleichen. Weiterhin haben Untersuchungen gezeigt, dass die Kosten für die Korrektur eines Fehlers unmittelbar von der Phase der Entwicklung abhängen, in der sie gemacht wurden. Je früher ein Fehler gemacht und je später er dann entdeckt wird, desto höher werden die Kosten für die Korrektur.
Einen besonderen Reiz hat die Analysephase, da hier IT-Experten mit den Experten anderer Gebiete zusammen arbeiten müssen, für die die Software erstellt wird. Die einfache Aufforderung „Schreiben Sie mal alle Anforderungen auf“ kann aus vielen Gründen nicht zum Erfolg führen. Einzelne Personen sind meist nicht in der Lage, ein gesamtes System zu überblicken, und Nicht-IT-Experten können kaum beurteilen, welche Informationen für die spätere Software-Entwicklung relevant sind. Weiterhin muss bedacht werden, dass sich Kundenmeinungen eventuell verändern und es ein Qualitätskriterium von Software-Projekten ist, konstruktiv mit diesen Änderungswünschen umzugehen. In diesem Kapitel lernen Sie, wie man feststellen kann, welche Personen für die Findung von Anforderungen wichtig sind und wie man systematisch zu Anforderungen kommen kann, die die weitere Entwicklung wesentlich erleichtern.
Stephan Kleuker
5. Grobdesign
Zusammenfassung
Das Ziel des Grobdesigns ist es, alle Informationen der Anforderungsanalyse in die Sprache der Software-Entwickler zu übertragen. Als Übersicht über die zu entwickelnde Funktionalität eignen sich die Klassendiagramme der UML. Dazu wird in diesem Kapitel gezeigt, wie man systematisch aus den textuellen Anforderungen des vorherigen Kapitels ein Klassendiagramm ableiten kann. Die Ableitung der Klassendiagramme erfolgt dabei iterativ. Abhängig von den Erfahrungen des Analytikers werden die Anforderungen schrittweise in das Klassendiagramm eingebaut. Die UML unterstützt dabei den Ansatz, zunächst Informationen unpräzise zu spezifizieren und diese dann in folgenden Iterationen zu konkretisieren. Das Ziel der ersten Klassendiagramme ist die vollständige Erfassung der gewünschten Funktionalität. Die Klassendiagramme werden dann im Feindesign so überarbeitet, dass sie zu einer gelungenen Implementierung führen.
Klassendiagramme sind eine so genannte statische Sichtweise, da man nur sieht, welche Funktionalität angeboten wird. Aus diesem Grund werden zu den Klassendiagrammen Sequenzdiagramme entwickelt, die zeigen, welches Objekt wann mit welchem anderen Objekt redet, also Methoden des anderen Objekts aufruft. Mit Sequenzdiagrammen entsteht so eine Möglichkeit zu prüfen, ob die z. B. mit Aktivitätsdiagrammen beschriebene Funktionalität mit der im Klassendiagramm spezifizierten Funktionalität realisiert werden kann.
Stephan Kleuker
6. Vom Klassendiagramm zum Programm
Zusammenfassung
Im vorherigen Kapitel wurde gezeigt, wie man aus einem Anforderungstext zu einem ersten Klassendiagramm kommt und wie validiert werden kann, dass das Klassendiagramm die Realisierung aller gewünschten Funktionalitäten ermöglicht. Dabei wurde durch die Sequenzdiagramme gezeigt, welche Methode von welcher anderen Methode aufgerufen wird. Offen bleibt dabei, was genau in den Methoden abläuft, was dann im Programmcode beschrieben werden muss.
Dieses Kapitel zeigt, wie man aus Klassendiagrammen so genannte Programmskelette generieren kann, die dann in der eigentlichen Implementierungsphase gefüllt werden müssen. Wir übersetzen dabei zu Lernzwecken direkt das erhaltene Analysemodell, was in der Praxis höchstens für Prototypen gemacht wird. In größeren Projekten wird man das bisher erreichte Klassenmodell durch weitere Modellierungen, z. B. durch Zustandsdiagramme und die genaue Formulierung von Randbedingungen der Form „Ein Projekt kann nicht Teilprojekt von sich selbst sein.“ ergänzen. Weiterhin gibt es viele Erfahrungen, wie man bestimmte Teilaufgaben mit speziellen Konstruktionen aus verschiedenen Klassen realisieren kann. Die Nutzung dieser ingenieurmäßig entwickelten Design-Ansätze führt dann zu einem besser zu realisierenden, besser zu wartenden, also zu korrigierenden, und besser zu erweiternden Programmcode. Diese Optimierungsideen werden in den nachfolgenden beiden Kapiteln vorgestellt. Um die tiefere Bedeutung dieser Kapitel zu verstehen und einen einfacheren Zugang zu diesen Themen zu haben, wird hier zunächst der grundsätzliche Weg vom Klassendiagramm zum lauffähigen Programm aufgezeigt. Die folgenden Kapitel zeigen dann Optimierungen und Verfeinerungen der hier vorgestellten Vorgehensweise, wobei von dieser in ihrem grundsätzlichen Ablauf nicht abgewichen wird.
Stephan Kleuker
7. Konkretisierungen im Feindesign
Zusammenfassung
Aus dem Analyseklassenmodell ist ein erster Vorschlag für die zu implementierenden Klassen bekannt. Im vorherigen Kapitel wurde gezeigt, wie man grundsätzlich zum laufenden Programm kommen kann. Praktisch als einzige zentrale Aufgabe des Entwicklers wurde genannt, dass die nicht trivialen Methodenrümpfe mit Inhalt gefüllt werden müssen. Gerade dies ist die spannendste und kritischste Aufgabe in der Implementierungsphase, da hier die Kreativität und die Fähigkeiten der Entwickler gefragt sind, die herausfinden müssen, wie eine informelle Beschreibung in das gewünschte lauffähige Programm umgesetzt wird.
Um die Lücke zwischen Klassendiagramm mit informeller Methodenbeschreibung und Implementierung nicht zu groß und fehlerträchtig zu machen, bietet die UML mehrere Möglichkeiten, wie Zustandsdiagramme und die Object Contraint Language, die Spezifikation der zu implementierenden Details präziser zu beschreiben.
Stephan Kleuker
8. Optimierung des Designmodells
Zusammenfassung
In den vorherigen beiden Kapiteln wurde gezeigt, wie man ein Klassendiagramm, das eventuell mit Zustandsdiagrammen und OCL-Constraints ergänzt wird, in Programmcode umsetzen kann.
Bereits am Anfang des Kap. 5 wurde erwähnt, dass das erreichte Analyseklassenmodell sich nur sehr bedingt für eine direkte Umsetzung eignet, gerade wenn es von unerfahrenen Modellierern erstellt wurde. Generell wird nach einem Klassenmodell gesucht, das möglichst alle drei der folgenden Eigenschaften vereint und durch Design Pattern ermöglicht wird Zunächst soll das Klassenmodell leicht änderbar sein. Kleine Änderungen sollen nicht dazu führen, dass man viele Klassenimplementierungen ändern muss. Weiterhin soll das Klassenmodell leicht erweiterbar sein. Neue Klassen, gerade Klassen, die Ähnlichkeiten zu existierenden Klassen haben, sollen leicht in das bisherige Klassengefüge eingebaut werden können. Dazu muss unter anderem die Lesbarkeit des Klassenmodells auch für Entwickler gewährleistet sein, die nicht an der Entwicklung beteiligt waren. Zu guter Letzt soll das Klassenmodell modulare Strukturen ermöglichen. Es soll Klassen ergeben, die eng zusammenarbeiten und nur möglichst einfache Verbindungen zu anderen Klassen haben.
Stephan Kleuker
9. Implementierungsaspekte
Zusammenfassung
Der eigentliche Weg vom Klassendiagramm zur Implementierung wurde bereits im Kap. 6 beschrieben. Dabei wurde gezeigt, wie aus einem Klassendiagramm die Programmskelette für die Realisierung abgeleitet werden können. Die Aufgabe der Implementierungsphase besteht darin, die generierten Programmskelette so zu füllen, dass alle Anforderungen erfüllt werden. Dabei geht es nicht nur um die algorithmische Umsetzung, deren Ideen in der Programmiergrundausbildung vermittelt werden, sondern auch um die Berücksichtigung vielfältiger projektindividueller Randbedingungen.
Statt alle möglichen Randbedingungen im Detail zu diskutieren, was den Raum mehrerer Fachbücher benötigt, werden in diesem Kapitel zentrale Implementierungsaspekte mit ihren Problemen angesprochen. Es wird dabei deutlich, dass einzelne Randbedingungen, wie die Entscheidung für den Einsatz einer bestimmten Technologie oder auch Programmiersprache maßgeblich für den Projekterfolg sein können.
Stephan Kleuker
10. Oberflächengestaltung
Zusammenfassung
In den bisherigen Kapiteln stand die Erfüllung der funktionalen Anforderungen im Mittelpunkt. Im Kapitel über die Implementierung wurde in einem Überblick gezeigt, wie nicht-funktionale Anforderungen berücksichtigt werden können. Insgesamt wurde dabei eine zentrale Anforderung für Software, die von Menschen direkt genutzt wird, vernachlässigt, die Nutzbarkeit.
Die Nutzbarkeit kann eine zentrale Anforderung für den Projekterfolg sein, da funktional korrekte, aber nicht intuitiv bedienbare Software bei Kunden kaum Akzeptanz findet. Zunächst ist es für Informatiker meist schwierig, mit Begriffen wie Nutzbarkeit und intuitiver Bedienbarkeit umzugehen. Ziel dieses Kapitels ist es zu zeigen, dass man diese Begriffe bis zu einem gewissen Grad präzisieren und überprüfen kann. Nach einem kurzen Einblick in die unterschiedlichen Aspekte, die hinter dem Begriff „Nutzbarkeit“ stehen, werden zunächst sehr generelle Anforderungen an die Nutzbarkeit formuliert, die dann schrittweise konkretisiert werden. Die Oberflächengestaltung muss in fast jedem Schritt des Entwicklungsprozesses berücksichtigt werden, die zugehörigen Aspekte werden vorgestellt. Abschließend wird gezeigt, wie man die Nutzbarkeit prüfen kann [SP05, RC02].
Stephan Kleuker
11. Qualitätssicherung
Zusammenfassung
Zum Ende des vorherigen Kapitels zur Oberflächengestaltung wurde bereits gezeigt, dass es wichtig ist zu überprüfen, ob das entwickelte System die geforderten Eigenschaften erfüllt. Für die reine Funktionalität der Software wurden in der Informatik vielfältige Methoden entwickelt, um sicherzustellen, dass die Anforderungen erfüllt werden. Diese Ansätze werden in diesem Kapitel vorgestellt.
Neben dem reinen Ausprobieren, dessen Ansatz man auch systematisieren kann, gibt es weitere Ansätze, die die Qualität der Software erhöhen können. Dabei spielt hauptsächlich das Qualitätsmerkmal der Korrektheit eine Rolle. Bei der Korrektheit muss man sich fragen „Korrekt bezüglich was?“, da eine Aussage „Das System ist korrekt.“ allein wenig Sinn macht. Korrektheit bezieht sich immer auf vorher gestellte Anforderungen. Nur wenn Anforderungen präzise gestellt werden, kann man die Frage, ob ein System die Anforderungen erfüllt, klar mit „ja“ oder „nein“ beantworten. Zentrale Aussage dieses Kapitels ist, dass man mit Tests nur nachweisen kann, dass diese Tests in gewünschter Form ablaufen können. Es wird damit nicht bewiesen, dass das System fehlerfrei ist. Durch die systematische Auswahl von Tests kann man die trotzdem noch möglichen Fehler begrenzen und validieren, dass die Nutzerwünsche erfüllt sind.
Stephan Kleuker
12. Umfeld der Software-Entwicklung
Zusammenfassung
In den vorherigen Kapiteln stand das ingenieurmäßige Vorgehen, also das systematisch durch Erfahrungen kontinuierlich verbesserte Verfahren zur Softwareentwicklung im Mittelpunkt. Gute Entwickler, die alleine gelungene Softwareprojekte mit OO-Ansätzen realisieren können, werden aber in großen Projekten schnell feststellen, dass das Entwicklungs-Know-how zwar zentrale Grundlage von großen gelungenen Projekten ist, es aber viele weitere Faktoren gibt, die ein erfolgreiches Software-Projekt und darüber hinaus eine erfolgreiche Software-Produktionsabteilung stark beeinflussen. Diese sehr unterschiedlichen Faktoren werden in diesem Kapitel angesprochen und grundlegende Einblicke vermittelt. Dabei ist zu beachten, dass es sich bei den folgenden Unterkapiteln meist um abgetrennte Forschungs- und Anwendungsgebiete handelt, die z. B. durch die angegebene Literatur vertieft werden können.
Auf der rein technischen Seite muss bei der Zusammenarbeit mehrerer Personen darauf geachtet werden, wer welche Dateien bearbeiten darf und wie sichergestellt wird, dass jeder mit den aktuellsten Versionen arbeitet. Weiterhin muss jeder Entwickler seine eigene Entwicklungsumgebung haben und geklärt werden, wie die entstehende Software auf Test- und Zielsystemen zu installieren ist. Diese Aspekte werden in den Unterkapiteln zum Versions- und Build-Management behandelt. Auf der organisatorischen Seite müssen Projekte geplant werden. Zentrale Grundlage ist dazu die Aufwandsschätzung, deren Ideen in einem eigenen Unterkapitel vorgestellt werden. Weitere Ansätze zum Projektmanagement werden danach diskutiert.
Stephan Kleuker
Backmatter
Metadata
Title
Grundkurs Software-Engineering mit UML
Author
Prof. Dr. Stephan Kleuker
Copyright Year
2018
Electronic ISBN
978-3-658-19969-2
Print ISBN
978-3-658-19968-5
DOI
https://doi.org/10.1007/978-3-658-19969-2

Premium Partner

    Image Credits